Vorbis - Apr 2005 - Problem with CPU usage on Playstation 2 when using Ogg Vorbis.

Hi,

Sometime ago i finished a port of Ogg Vorbis to Playstation 2.
The code is working just fine and the music sounds like it should, but 
there is one problem.
I get CPU usage that looks like this (when i say frames i mean actually 
rendering frames on the
Playstations 2 and you have 50 or 60 frames per second)

cpu usage:        ~100%         ~0%         ~0%          0%         ~100%
current frame:        0                1             2               
3                4

This indicates that the Ogg Vorbis code processes a bit a head and on 
frame 0 decodes
data for frame 1-3 also and just "gives" that data back for the 
following frames.

What this means is that i will get frame drops every 4th frame (as i 
need to use the main CPU
to do other things than just playing music)

So i wonder if its possible to get a more even cpu usage across each 
update? lets say
it will take 25% each time instead of the pattern above?

If anyone has any pointers that would help me out i would be very thankful.

Thanks

Daniel

On Sat, Apr 30, 2005 at 11:34:11AM +0200, Daniel Collin wrote:
> This indicates that the Ogg Vorbis code processes a bit a head and on 
> frame 0 decodes
> data for frame 1-3 also and just "gives" that data back for the 
> following frames.
>From the timing, I'd guess what happens is that the vorbis decoder is 
decoding a full packet at a time, which is enough audio to span several 
frames. As you say, requests for successive frames' audio just copy from 
the already decoded buffer.

If you can't just spawn a thread for the decode loop, I think you'll 
have to hack the decoder to be interruptible, and perform only some 
number of decoding steps each frame. Since dropping audio is worse than 
dropping video, you'll probably want to make this adaptive, so the 
vorbis decode always gets done, but the steps are distributed over some 
number of calls. The joys of cooperative multitasking. :/

You could also experiment with feeding it smaller amounts of data in 
case it's decoding multiple packets at once, but IIRC (and from the 
timing) it just does a packet each time.

Hope that helps,
 -r
> So i wonder if its possible to get a more even cpu usage across each 
> update? lets say
> it will take 25% each time instead of the pattern above?
Could also try to optimize the decoder so it just takes less time, of 
course. :) I can't remember, is your code based on tremor, or libvorbis?

>>I get CPU usage that looks like this (when i say frames i mean actually 
>>rendering frames on the
>>Playstations 2 and you have 50 or 60 frames per second)
>>cpu usage:        ~100%         ~0%         ~0%          0%        
~100%
>>current frame:        0                1             2               3
>>            4
The fundamental problem is Vorbis can use window sizes larger than the 
amount of samples than naturally want to be processed each 60 Hz frame draw. 
E.g. at 48 Khz, about 800 samples would be processed each frame draw. Vorbis 
doesn't use window sizes of 800. If it did (in a dream world), you
wouldn't
be having issues.

I believe Vorbis will often use window sizes of 2048. So your peak CPU hit 
in a frame draw will be 2048/800 percent above the average CPU load.

One thing you could try doing is modifying the encoder to only use frame 
sizes as large as 1024. This will cut your peak CPU in half. You could go to 
512, but I don't think it would help the worst peaks as you will have to 
decode 2 512 size windows sometimes. Even 256 wouldn't help the peak as you 
would still need 4 of them. 128 would start to see some returns as you would 
need at most 7. But at that point you are reducing the efficiency of the 
compression considerably, and you probably eat any CPU savings back 
processing those small windows. The smaller numbers below 512 only get you a 
more even CPU distribution between frames (which doesn't do much good in 
video games as it's the peak that kills you). Keep in mind limiting to 1024 
means you can only play your own Vorbis files, if that's an issue. You also 
reduce the amount of compression possible.

Other than that, looking at the numbers I think you want to do a pile of 
optimization as it looks like you are using at least 25% CPU anyway. Unless 
your PS2 application can afford that CPU (that would be surprising), load 
balancing improvements are a bit pointless unless you optimize as well. I'm 
pretty sure libvorbis would run dog slow on a PS2 out of the box.

The idea of running Vorbis on a separate thread at a lower priority is also 
interesting, although perhaps a bit messy. The biggest issue on PS2 is it is 
cooperative, so you would have to implement a watchdog interrupt of some 
sort (e.g. the VBL) that could force the low priority Voribis thread(s) to 
yield when the CPU is needed again for other threads.

I've always thought it would be pretty easy to produce a version of Vorbis 
that is more friendly to video games. It would encompass at least a few 
changes, including the window sizes. Out of the box, Vorbis is not the most 
friendly format for in game music/SFX in video games (e.g. MP3 slides into 
video games easier, at least on a technical level). Not trying to push MP3, 
I'm just saying I think it would be very easy to remove the obstacles in 
Vorbis to the point where it would behave similar to MP3 in regards to CPU, 
memory, and usage.

Thanks,
Dave.