hi,<br><br>I am pleased to introduce GSmartMix. GSmartMix has
recently been accepted to Google SoC. It aims is to bring a new sound
experience in Gnome. Thus, I guess this effort should be discussed
here.&nbsp; Ensonic, Stefan Kost, is the mentor of this project. Raphel
Slinckx is the co-mentor.
<br><br>If you are not already familiar with this project, you could have a look at <a href="http://live.gnome.org/GSmartMix" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://live.gnome.org/GSmartMix
</a> before reading this.&nbsp; I will also do my best to change the GNOME
sound support, but *it's not* the main goal. For the moment, GSmartMix
is a project that I want to design to be run aside and optionnaly,
without any API change.
<br><br>The following are some technical suggestions on GSmartMix, I would like to discuss with you.<br><br>Please note: <br>GNOME API and esd discussions will go in gnome.multimedia mailing list.<br>I don't make any difference between rule or class for the moment: it's a description of the sound: &quot;music&quot;, &quot;voice&quot;, &quot;event&quot;...
<br><br>=== UI ===<br><br>The ui provide a per class sound level sliders, and some rule parameters:
<br>- foreground sound level<br>- background sound level<br>- fading speed<br>- and list of class that we put in foreground when this class has to play<br>(queue policy: first in stay in fg (fifo), last in go in fg (lifo), none (all fg))&nbsp;
<br><br>I would like to add a new tab in the GNOME &quot;Volume Control&quot; application with this content: <a href="http://live.gnome.org/GSmartMix/TechnicalChoices?action=AttachFile" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">






http://live.gnome.org/GSmartMix/TechnicalChoices?action=AttachFile </a><br><br>Regarding the Topaz mockup of volume controler and the per-app volume control (<a href="http://static.flickr.com/20/70003494_668cfdc0dd.jpg" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">






http://static.flickr.com/20/70003494_668cfdc0dd.jpg</a>):
GSmartMix benefits will partially fit this. I don't know how we could
deal with &quot;multiple instance of an application&quot; problem... 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
&quot;foreground app&quot; per class for common sounds (voice, video, music..)
will help to clean up this list. This way, only &quot;foreground app&quot; will
be shown in the list. Only some class, like &quot;events&quot; won't need this
&quot;front&quot; scheme. We don't care of a per app &quot;event&quot; sound level
probably.Is it really what we want? <br><br>=== Sinks: a new element or a gstbaseaudiosink integration ===<br><br>I have tried to depict my initial overview of GSmartMix here: <a href="http://live.gnome.org/GSmartMix/TechnicalChoices?action=AttachFile&amp;do=view&amp;target=overview.png" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">





http://live.gnome.org/GSmartMix/TechnicalChoices?action=AttachFile&amp;do=view&amp;target=overview.png</a><br>&nbsp;<br>Different design solutions can be thought up. What will be the best or the consensus?
<br><br>==== &quot;Base patch&quot; solution ====<br><br>The idea is to handle
dbus communication at the baseaudiosink class level. ensonic, how would
be handled the volume control/transformation at this level? <br>This way, every audiosink will be seen over dbus.
<br><br>Drawback: <br>- all compiled audio sinks will have a libdbus dependency (if we compile gstlib with this support)<br>- intrusive patch in gst<br>- every app will have to suffer/benefit the smart level control <br>







<br>
==== &quot;New element&quot; solution ====<br><br>Formerly, I was thinking
of a kind of GStreamer &quot;identity&quot; bin elements, inserted before the
real audio sink. They will catch some gstramer events
(status/streaminfo..) and send them over dbus. After that they will
obey GSmartMix server orders and update a volume level. The &quot;volume&quot;
element manipulated would be found by looking up the parent bin. The
&quot;volume_element&quot; 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 and in GStreamer. <br><br>Look at this sketch: <a href="http://photos1.blogger.com/blogger/2015/2884/1600/sec.2.png" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://photos1.blogger.com/blogger/2015/2884/1600/sec.2.png
</a> <br><br>Drawback:<br>- another plugin =&gt; a different pipeline
<br>- all applications/usage will not benefit from GSmartMix (those who use directly alsasink for instance) <br>- more complex solution?
<br><br>==== Polypaudio ====<br><br>jeff pointed me out Polypaudio. I
was not thinking hard of using it, because it sounded like an odd but
good esd replacement. Which is not the aim of my work. But, I must
admit I am quite impressed by its state. It features some of the
required interfaces for my project. Definetly, my will is to fill the
gab between gnome, gstreamer and polypaudio.
<br><br>Recent discussion with lennart on #polypaudio about GSmartMix: <a href="http://pastebin.com/747392" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://pastebin.com/747392</a><br><br>Drawback (if the effort is to patch polypaudio):
<br>- the volume level adjusted at the server side will not be updated
in the client side (for example, the volume slider of your favourite
music player): I believe I can fix this or is there already a solution
in polypaudio? The polypaudio author, Lennart, will post on this
subject, onthe&nbsp; GStreamer GstMixer flaw.
<br>- we still depends officialy on a sound server (and not on ALSA/dmix), which could be badly interpreted<br><br>==== Remarks ====<br><br>- I believe sinks must initialise and &quot;block&quot; sound output until the dbus server did not reply to adjust their level. 
<br><br>- 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 &quot;class&quot; and &quot;priority&quot;. Could it be done with standard
GStramer API, with a bus message ?
<br><br>=== GSmartMix, a dbus server ===<br><br>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 ?).&nbsp; So
that the server could be written with light C code. If more freedom is
required, Python is probably the language of choice. <br>But, it could be written differently.<br><br>I also wonder how
the dbus server could monitor its slaves: the communication need to be
in a &quot;connected&quot; mode with the peer (I think of an application crash,
an abnormal behaviour...).
<br><span class="sg"></span><br>-- <br>Marc-André Lureau, GSmartMix