Ogg vorbis performance.

[Russell Sears]

Sören Apel wrote:
> On Thu, 2008-07-17 at 08:27 -0700, Russell Sears wrote:
>> Russell Sears wrote:
>> I uploaded a fix to the bug tracker.  It bypasses PulseAudio and uses 
>> ALSA.  Any idea why that helps?  In principle, ALSA and PulseAudio 
>> should have to perform the same computations to play the sound back 
>> (alsa contains a software resampler...)  I haven't been able to find any 
>> obviously mistakes in the configuration files.
> 
> It's been a while but from what I remember, the PulseAudio plugin puts
> contraints on the data stream that are incompatible with the libtremor
> format, which in turn enforces sample conversion to take place. The ALSA
> plugin may not have these constraints.
> Again, that's from memory so I'm not 100% sure on what the cause was
> exactly.
> 

It's strange; the hardware seems to only support 48khz, but ALSA and 
PulseAudio want 44.1.

Also, I somehow forced PulseAudio to accept an integer 44.1 khz stream, 
but then it took 80% of the CPU to do the resampling instead of 40%...

>> Also, are there any bad implications to bypassing pulseaudio?  I haven't 
>> noticed any.  I'd like to get ogg vorbis (and anything else that outputs 
>> 16bit/44.1kHz) fixed in the official image...
> 
> PulseAudio is great and would allow for great things - e.g. seamless
> audio stream moving (play files on Neo, have them come out of your
> desktop soundcard). Aside from that, PulseAudio also allows for
> simultaneous usage of the soundcard, which ALSA still has issues with.
> Dmix, esd & friends pale in comparison to PulseAudio as well.
> 

Seamless stream moving would be cool.  gstreamer supports that (though 
maybe not on the fly).  It sounds like pulseaudio can also do 
synchronization of multiple audio devices, and other neat tricks.

So far, I haven't noticed any difference between ALSA and PulseAudio's 
handling of multiple applications sharing the soundcard.

> Of course any intermediate layer will affect performance and even more
> so as tons of applications still try to access ALSA directly - which
> would only work with a plugin on top of PulseAudio to allow this, or
> ugly workarounds like pasuspend.

Right; but it shouldn't be as expensive as decoding(!)  If we can get it 
to do efficient resampling, then I suspect the problem will go away and 
hopefully so will some of the constant CPU used by pulseaudio when it's 
idle...

> 
> mickey told me that FSO doesn't use PulseAudio anymore. You might want
> to see how they solved the ALSA problem there or whether they just left
> PulseAudio out and ignore the problem of having several apps trying to
> access ALSA at the same time.

I expected it to cause problems with multiple apps, but it seems to work 
correctly on my phone.  I'm running an updated version of the factory image.

It's slightly off topic, but has anyone looked into adding a software 
equalizer to mediaplayer?  The hardware one exposed by alsamixer doesn't 
seem to have much effect.

It looks like a ladspa package exists, but I'm not sure if that's the 
right choice for a platform without a floating point unit.

> 
>  -Soeren