Amarok + PulseAudio: volume control changes global volume

Colin Guthrie gmane at colin.guthr.ie
Thu Jul 8 18:54:13 BST 2010


'Twas brillig, and Martin Sandsmark at 08/07/10 18:03 did gyre and gimble:
> On Thursday 08 July 2010 18:01:26 Colin Guthrie wrote:
>> This blog post explains it better than I could regurgitate it here.
>>  http://0pointer.de/blog/projects/pulse-glitch-free.html
> 
> The blog post explains (in Lennart's usual long-winded style :-P) what it is, 
> but not why it isn't implemented in ALSA, instead of in PulseAudio (which 
> would make more sense, since AFAIK PulseAudio is crossplatform, and CoreAudio 
> and Vista already does this properly, and also it would be much less hackish).
> 
> And has there been done any benchmarks on the impact of this on battery life? 
> Or some basic profiling? As I said, in my own experience, PulseAudio (still?) 
> has a rather detrimental effect on battery life (which also makes sense to me, 
> since PulseAudio adds overhead to all audio operations, and now also adds 
> extra timer interrupts with a much increased overhead compared to the "normal" 
> interrupts from the sound card).

I'm not aware of public benchmarks but I know folks at Intel have done
them. Intel has been one of the primary drivers behind this approach...
for obvious reasons. They've been experimenting with pretty large
latencies of up to 10s or so, but as I mentioned earlier it has to be
done in tandem with the client applications. On embedded systems it's
obviously easier to control the whole pipeline.

Clearly the timer based "interrupts" are far less frequent than the
normal interrupts which are of course disabled.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]



More information about the kde-multimedia mailing list