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" <[email protected]>:
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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
