Amarok + PulseAudio: volume control changes global volume
gmane at colin.guthr.ie
Thu Jul 8 17:01:26 BST 2010
'Twas brillig, and Martin Sandsmark at 06/07/10 19:09 did gyre and gimble:
> On Tuesday 06 July 2010 15:21:46 Colin Guthrie wrote:
>> That's a shame. Be warned that as time marches on, most users and thus
>> most testing will end up using PA. The power savings (particularly
>> important on mobile devices) and unification of audio settings are
>> probably the primary reasons for doing this.
> Sorry for being a tad bit off-topic, but where does the power saving come
> from? IIRC, there was a mention of increasing the buffer sizes, but doesn't
> that make much more sense to do in the drivers?
It's basically the timer-based driver model of PA (aka "glitch-free" -
although a somewhat ironic name due to the driver bugs it unearthed when
first deployed resulting in, you guessed it, glitches!) rather than the
traditional interrupt driven model of ALSA.
This blog post explains it better than I could regurgitate it here.
Of course all this cleverness doesn't really do much if all the clients
(i.e. audio producing applications) all claim to want/need low
latencies. There are several places where low latencies are needed, but
there are also several places where they are not.
To put this into a Phonon context, there is currently no way via the
Phonon API for an application to say what kind of latencies it needs and
thus no way for us to pass this through the backends to PA. This limits
the scope of Phonon in a mobile environment and I would like to address
this in due course.
Currently, AFAIK, only GStreamer backend supports setting up PA in a way
that would actually take full advantage of glitch-free (by passing the
‘buffer-time’ and ‘latency-time’ parameters to pulsesink). VLC has no
concept of this in it's PA output layer (which is actually quite simple
and could do with ninjafication). Xine also does not expose this (in
theory we can setup some env vars, but that is pretty hacky and may not
work reliably on all backends anyway).
So while GST generally does expose the power savings if used properly,
nothing right now in Phonon will actually use it, including the GST backend.
These are all "on my list" but I seem to find myself bogged down with
all sorts of things these days to find much time to concentrate on it.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
kde-multimedia mailing list
kde-multimedia at kde.org
More information about the kde-multimedia