1. DESIGN
1.1. UI
The mockup of Topaz mixer is great (see GSmartMix/Proposal). GSmartMix benefits will partially fit with this. I don't know how we should deal with "multiple instance of an application" in the list... This is why I was briefly thinking of a Metacity integration, in order to differenciate each sound source easily. But I am wondering if one "leader app" per class for common sounds (voice, video, music..) will help to clean up this list. This way, only "queue heads" would be shown like the mockup. Only some class, like "events" won't need this "head" scheme. We don't care of a per app "event" sound level probably.
Is it really what we want? I also would like to bring a new tab in the "Volume Control", providing a per class sound level sliders, and some parameters (lifo/fifo, queued sinks volume, fading speed)
1.2. GSmartSink, sinks & dbus clients
- In fact, they are kind of GStreamer "identity" bin elements, inserted before the real audio sink. They will catch some meta-data events and send them over dbus. After that will obey GSmartMix server orders and update a volume level. The "volume" element manipulated might be found by following the GStreamer elements chain up to it: this "volume_element" property could be overriden. If none is found, a new one will be added in GSmartSink bin in order to control volume output. This way, I hope to be able to provide GSmartMix without having to change anything in the application side. Would it be technically possible ?
Yes, it is.
1.2.1. Remarks
- I guess sinks must initialise and "block" sound output until the dbus server did not reply to adjust their level.
- of course, I would also like to bring new things to the client side, like the ability to describe sound, like the ability to give sound "class" and "priority". These things will be discussed later.
I rise a question, (especially to kikidonk): Do you think that using and updating the "now playing" element of GShrooms could lead to a more modular code? "now playing" and "dbus volume ctrl"
1.3. GSmartMix, a dbus server
I like the simplicity of devil's pie. I wonder if I could improve s-exp interpreter to support GSmartMix needs (fifo on class, loops on other sinks ?). So that the server could be written with light C code. If more freedom is required, it could be written in Python.
I also wonder how the server could monitor its slaves: the communication need to be in a "connected" mode.