[pulseaudio-discuss] Software volume: linear vs. logarithmic

[Jaska Uimonen]

Hi,

I don't know if I have understood everything correctly in the
pulseaudio volume handling, but almost all operations seem to
boil down to pa_sw_volume_to/from_linear - function, which has
inherent cubic mapping. So (if I got this correct) if you
do linear fade with pa_volume_t, you get cubic mapping.

If you want to do some other shape, you should then first
cubic root your pa_volume_t values (to linearize) and then
induce your curve on top of it (?). If you just do some
mapping on top of pa_volume_t, you get some kind of combined
cubic + your own mapping...

br,
Jaska


Quoting "Arun Raghavan" <arun.raghavan at collabora.co.uk>:

> On Wed, 2012-08-22 at 15:14 +0200, "Günter Merz" wrote:
> [...]
>> I would like to do something similar to what I did in xine to  
>> pulsesink.c in the gstreamer-good package in order to change the  
>> rhythmbox and rygel (and others) volume handling but the fact that  
>> Lennart Poettering (once the lead developer) originally wrote the  
>> GStreamer pulseaudio plugin and will surely have had his reasons  
>> for doing it the way he did makes me ask here first.
>
> This is the standard across all elements implementing the volume
> property, and makes sense as it maps more naturally to underlying APIs
> and hardware. The idea of a cubic mapping (or any other natural-sounding
> mapping) should be left as an application decision and does not belong
> in middleware layers.
>
> To make things easier for GStreamer-based applications, there is a
> GstStreamVolume interface which can do a cubic mapping if requested.
> You'll notice that Rhythmbox actually does this already:
>
> http://git.gnome.org/browse/rhythmbox/tree/backends/gstreamer/rb-player-gst.c#n311
>
> -- Arun
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>