Question about the mp3 sample found in the sdk

[sauron_le_noir]

In the sdk there is a sample made bij raphael that show how to playback a mp3
the model used is a simple thread like this

open the mp3 file
while( true )
{
if data_needed_to_the_audio_playback
read data from mp3 file
set in buffer

play mp3
}
it work great but when in the loop i call a function that use a lot of cpu
the mp3 playback begin to be choped.

What function must i use to yeld the cpu if instead of using a simple thread model i'm using 2 threads one for the mp3 playback et one for the game

Does a sleep(0) set in the game thread give the focus on the mp3 thread ?
psp multitasking is cooperative so i cannot use some kind a timer because
in the main thread i use a lot of cpu without calling any psp function
so i want to give my cpu time back to the system so the mp3 thread got a chance
to play is file.

Thx for the response the homebrew being develloped is a mahjong game. In the game i use a backtrack algoritme to find all combinaison of the tiles

[J.F.]

Most folks use something like "sceKernelDelayThread(10);" to do that. 10 usecs doesn't affect the thread all that much, but does allow higher priority threads to run if they're ready.

[sauron_le_noir]

Thx for the reply JF i have just changing the logic of my game
i call the backtrack routine just when needed it is better but i heart chop
when i call to the backtrack routine.
i hope implementing a 2 thread logic will avoid this
there is another alternative when performing the backtrack code increase the cpu
speed to 333mhz but i don't like this i prefer give a chance to the mp3 thread

[J.F.]

I'm not certain about the mp3 decoding path, but this is generally an issue with all audio playback code. Many wait until the last sample plays, then call a callback routine to fill the buffer. This means you have one sample period to fill the buffer. If the audio callback just signals another thread (semaphore), you may have to wait on a task switch as well. If the code to fill the buffer is complex (wavetable synth or decompression like mp3 or ogg), you can get pops in the audio. The proper way to do it is to set up multiple buffers (at least two) and fill (at least) one. Then start that buffer playing and immediately fill the next buffer. When the thread playing the audio finishes the buffer, it merely switches to the next buffer and signals the fill thread the previous buffer is now free. Keeping (at least) one buffer ahead means you have N x sample period (where N is the size of the buffer) in which to fill the next buffer. Depending on how much latency there is between the threads and the manner in which buffers are filled, you may need more than two buffers. My OpenAL example that plays the microphone out the speakers is an example - three buffers weren't enough. For most games or simple audio players, double-buffering is fine. If you look at all my audio playback routines for things like DOOM and Basilisk II, I use two buffers. My example ogg and flac player also only needed two buffers.

[sauron_le_noir]

Thx JF for your input i take a look at you open AL code