gstreamer/docs/random/ensonic/media-device-daemon.txt
Stefan Kost 08501e5b3a docs/random/ensonic/media-device-daemon.txt: more ideas (dbus)
Original commit message from CVS:
* docs/random/ensonic/media-device-daemon.txt:
more ideas (dbus)
* gst/gstbuffer.c:
fix doc example, add clarification
* tools/gst-launch.1.in:
add initial info about GST_PLUGIN_PATH, needs more work
2006-01-11 19:18:27 +00:00

42 lines
1.4 KiB
Text

$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 incomming call, if pauses your
media-player, or mutes the monitoring of your recording app