Ogg vorbis performance.

Russell Sears sears at cs.berkeley.edu
Fri Jul 18 08:43:12 CEST 2008

Troy Benjegerdes wrote:
>> It should have essentially zero overhead when properly configured, and 
>> when its not doing anything fancy.  I don't think these performance 
>> problems are fundamental.
> Don't think, benchmark :)  There are a ton of non-obvious reasons one
> approach might seem just fine but really suck. (cache alignments, tlb
> misses, ctx switch overhead)

One step ahead of you.  Thats how I found out about the floating point 

The reason I think that the performance overhead will be negligible is 
that it should be using shared memory to pass the data around, and it 
should never actually copy / touch the audio data inside of pulseaudio 
unless it hits a hardware / alsa limitation.  We can crank up the buffer 
size (and latency) if things like context switches cause trouble...  At 
any rate, we can't measure anything until we get rid of the floating 
point resampling...

>>> For power and performance reasons on a cell phone, I think anything a
>>> sound server does would be much better done in the kernel-level ALSA
>>> drivers. The only downside I can see to this approach whether the
>>> in-kernel bluetooth audio drivers are any good.
>> Kernel-level software resampling should be just as expensive as 
>> userspace resampling...  Pulseaudio does seem to do some soft-realtime 
>> stuff and adds a bit of device transparency.
>>> Last I tried bluetooth-audio on my laptop I had to run a userspace
>>> daemon.
>> I have no idea what would happen with Alsa if you tried to transfer a 
>> call between the speaker and the bluetooth set.  I think pulseaudio can 
>> handle this sort of thing correctly.
> All my whining aside, seamless speaker->bluetooth handoff seems to be a
> 'must-have' feature. Although I would like to hear a good reason why the
> kernel shouldn't be in charge of that.

Well, it's kind of a user space thing, since they're two different 
(unrelated) devices.  Also, pulseaudio can hand off audio over the 
network, and supports some sophisticated audio processing stuff that 
probably shouldn't live in the kernel...

On the other hand, for all I know, ALSA or some simple hack may be able 
to handle the bluetooth thing...

>>> Speaking of which.. do we have any way to measure the power consumption
>>> of playing a reference .ogg file without special hardware? Are the
>>> built-in battery charge management counters good enough?
>> Good question. :)  Also, pulseaudio may be preventing the sound card and 
>> cpu from falling asleep, even when no sounds are being played.  From 
>> what I can tell, it's been configured to never go idle.

More information about the openmoko-devel mailing list