$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-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
-- daemon that holds list of instances
-- gui app that 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 incomming call, if pauses your
+ - think of a voip-client, if there is an incoming call, if pauses your
media-player, or mutes the monitoring of your recording app