Re: [pulseaudio-discuss] Software volume: linear vs. logarithmic
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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Software volume: linear vs. logarithmic
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.ragha...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Volume ramp
Hi folks, A few weeks ago Jaska Uimonen sent a set of patches implementing the volume_ramp. I've playing with his patches and proposing some fixes/changes, i guess he will send a new patch soon. Meanwhile I've created a public repository (http://git.profusion.mobi/cgit.cgi/ceolin/pulseaudio/) with this code + support for multichannel. I expect this will make easier for whom intend to review this code. The repository contains two branchs, the ramp with the volume_ramp code, and the branch ducking implementing the module with ducking effect (patch already sent to list too). Comments are welcome :) Best Regards, Flavio Ceolin ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] resampler: Fix crash if 'auto' resampler chooses ffmpeg with variable rate
2012/8/24 Tanu Kaskinen ta...@iki.fi: On Wed, 2012-08-22 at 19:31 +0530, Arun Raghavan wrote: On Wed, 2012-08-22 at 15:42 +0200, Frédéric Dalleau wrote: [...] diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c index 17f1783..8199bc4 100644 --- a/src/pulsecore/resampler.c +++ b/src/pulsecore/resampler.c @@ -237,7 +237,10 @@ pa_resampler* pa_resampler_new( #ifdef HAVE_SPEEX method = PA_RESAMPLER_SPEEX_FLOAT_BASE + 3; #else -method = PA_RESAMPLER_FFMPEG; +if (flags PA_RESAMPLER_VARIABLE_RATE) +method = PA_RESAMPLER_TRIVIAL; +else +method = PA_RESAMPLER_FFMPEG; #endif } The trivial resampler is not a good fallback. I'd rather make speex a mandatory dep again. Whether or not the trivial resampler is a good fallback depends on the use case. If someone thinks that it's a good idea to compile pulseaudio without speex support, then I would expect him to be fine with the trivial resampler (otherwise he wouldn't have disabled speex support). Besides, I once profiled and it showed the trivial resampler is much faster, esp on resource limited embedded boards. Hmm, the output sound is not so much bad... ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] resampler: Fix crash if 'auto' resampler chooses ffmpeg with variable rate
2012/8/25 rong deng dzro...@gmail.com: Besides, I once profiled and it showed the trivial resampler is much faster, esp on resource limited embedded boards. Hmm, the output sound is not so much bad... to be correct, i shouldn't have said faster, actually the cpu usage is lower. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
