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 >
