blob: d16ee0bb61139ae090f62c7d31d22f5fb15b2fa1 [file] [log] [blame]
$Id$
components
================================================================================
- daemon process
- is a gstreamer appliation
- open physical sink, src elements
- prepends an adder to sinks
- appends an tee to sources
- listens to dbus, to get notified by virtual-endpoints of init/finalize
(the dbus notify, would also be useful for gst-editor to hook on running
apps)
- 4 new elements
- virtual-audiosink, virtual-videosink
virtual-audiosrc, virtual-videosrc
- virtual sinks establish a connection to the daemon
- they link to request_pads of the adder/tee elements
- on init and finalize they send a dbus-message
- gui app
- lists instances as mixing-desk like channelstrips
- channelstrips would contain
- audio
- volume, panorama, 3-band eq
- video
- brightness, contrast, alpha-level
- user can
- add insert-fx
- route channel to targets, where targets can be real sinks or more
virtual-sinks (sub-groups)
- virtual sinks need queues to decouple application processes
- interfaces
- expose child-elements via child-proxy
- then e.g. the applications volume-control could directly access the
channelstrip
- state-control (play, pause/mute)
- it would be useful if one app could pause/mute others
- think of a voip-client, if there is an incoming call, if pauses your
media-player, or mutes the monitoring of your recording app