Ogg vorbis performance.

Russell Sears sears at cs.berkeley.edu
Thu Jul 17 17:27:37 CEST 2008


Russell Sears wrote:
> Flemming Richter Mikkelsen wrote:
>> On 2008-07-13, Russell Sears <sears at cs.berkeley.edu> wrote:
>>> Sören Apel wrote:
>>>> Heya,
>>>>
>>>> On Sat, 2008-07-12 at 14:27 -0700, Russell Sears wrote:
>>>>
>>>>> I've noticed that my freerunner is *almost* fast enough to play my ogg
>>> vorbis files; running a second app, or even gpsd causes the media 
>>> player to
>>> skip, then to go silent.
>>>> Yep.
>>>>
>>>>
>>>>> What's been done to get ogg vorbis to perform well so far?  ogg123,
>>> oggdec seem to be able to decode in roughly 2/3's realtime, which is 
>>> similar
>>> to the CPU usage of openmoko-mediaplayer.
>>>> If I remember correctly it was a problem with the sample rate/sample
>>>> format,
>>>> meaning that resampling had to take place - which eats CPU like candy.
>>>>
>>> Ouch.  What sample rate does the hardware provide, and does 
>>> pulseaudio or
>>> gstreamer do the resampling?  Also, decoding to /dev/null is slow...  
>>> That
>>> shouldn't resample should it?
>>>
>>> I've noticed that things I've encoded more recently seem to be less 
>>> likely
>>> to play (perhaps I changed an encoding setting at some point...), but 
>>> that
>>> it varies from track to track...  I'll time some files, and see if I can
>>> find a pattern.
>>>
>>> Thanks!
>>>
>>> -Rusty
>>>
>>>
>>>>
>>>>> I noticed that gstreamer is using libvorbisi (tremor) since there 
>>>>> is no
>>> floating point unit.  It looks like there are three ways to make it go
>>> faster:
>>>>>  - Tremolo, which is ARM specific, and claims 15-20% better 
>>>>> performance
>>>>>  - _LOW_ACCURACY_ mode
>>>>>  - The "low-mem" branch of tremor
>>>>>
>>>>> Which of these have been tried so far?
>>>>>
>>>> None, as I didn't find the time unfortunately. You're more than 
>>>> welcome to
>>> try these :)
>>
>> I use my Freerunner as a mediaplayer. I installed mplayer and stored
>> my ogg vorbis files on the micro SD card. They are encoded with high,
>> but floating bitrate.
>>
>> I got no problems when playing.
>>
>> Also, please note that ogg vorbis is extremely flexible and you can
>> select any bitrate for playback without the need for reencode.
>>
> 
> There is now a bug for this, number 1614.
> 
> I'm beginning to agree with Sören; I think it's resampling or doing 
> software mixing in the pulseaudio layer.  Getting pulseaudio to perform 
> passthrough will probably help.
> 
> Also, I'm attempting to build all the packages from scratch, and figure 
> out who links to which vorbis decoder, and with which compilation 
> options.  Hopefully, we can save some cycles there too.
> 
> -Rusty
> 

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.

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...

-Rusty



More information about the openmoko-devel mailing list