'Twas brillig, and David Henningsson at 09/05/12 02:36 did gyre and gimble:
> We had some sound related discussions today at the Ubuntu Developer
> Summit, which I just wanted to write down and share with you before I
> forget about it...
>
> 1) Icons per port
> The new sound settings UI exposes ports as its primary object and as
> such it would be nice to have one icon for the Headphones port and
> another icon for the Speaker port.
> From what I can tell this would be quite simple? As Tanu has written
> infrastructure that can take port properties from the path .conf file,
> and that is then exposed to client.
Yup, I think icons were actually one of the reasons I was keen on having
the proplist there for the ports. Makes sense IMO.
> 2) +11dB
> The people within the discussion - including myself - seem to mostly
> agree that for the sound settings UI, it makes most sense to remove the
> possibilty to set more than 0dB output for the device volume, but
> instead allow it for stream volumes. The argument is that the most
> common use case for this is that you're listening to DVD/flash movies,
> where the particular application would be what's bothering you.
> Therefore it would make more sense to boost the application, rather than
> the device.
Interesting idea. However, as you guys do not use flat volumes, how can
a volume >0dB for a stream ever make sense if the system volume is at
-30dB? As it doesn't make sense to push a stream volume >0dB if the
system volume is anything less than 0dB itself, would you be adopting
flat volumes to implement this feature? If not then a stream volume of
+11dB with a sink volume of -30dB would result in -19dB overall for that
stream which doesn't, to me, seem like the clearest method of presenting
this feature. Internally I would hope that this could be implemented
sensible (i.e. setting the hardware to -19dB even if we present the sink
volume as -30dB and attenuate other streams accordingly etc. etc.), but
this may make the the number of volume objects we track even more
confusing (although it may fit the current module anyway?)
And if you do adopt flat volumes, as the sink volume is always no less
than maximum of the stream volumes, how would you present that in the
GUI? Would it just limit the slider but still allow it to be technically
>0dB (much like the media keys on keyboards are handled just now)?
I've probably complicated this idea for you now :p
On a related note, it's maybe also worth thinking about how "0dB" is
handled on different h/w. e.g. how do we deal with "Base Volume" on
hardware where "all ALSA sliders at max" != 0dB.
IMO, we should have a per-sink/source persistent setting that allows us
to opt to use the ALSA 0dB point as our 0dB point (thus effectively
opting to NOT have a base volume on this device (as if turned on, base
volume == 0dB == 100%).
Of course in this setup, we'd still want volumes >0dB (boosted) to use
the alsa controls to do that rather than software amp while not making
full use of the kcontrols.
> 3)
> Some questions were raised about PulseAudio's ABI stability. I think
> we're pretty hard on not introducing anything that breaks the ABI for
> clients, ever, but what about modules? I'm assuming that since modules
> can call into the core very arbitrarily, we would not assume any kind of
> ABI stability for modules, not even between stable releases (1.0 to 1.1,
> e g). Is that correct? I e, if I compile a module against 1.0 and
> distribute the binary, once PA 1.1 is rolled out, there is a possibility
> that my module will crash PulseAudio unless the module is recompiled
> against 1.1.
Yup, as Tanu said, modules compiled "out of tree" are not officially
supported for exactly this reason. We don't want to limit ourselves to a
stable A{P,B}I here.
Cheers
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
