audio system collapse? (was: problem with threads/gu)

[jonny]

i'm encountering a strange problem.


basically i have 2 threads:


TH_A:
the first thread produce frames in a ring buffer (in memory).
it also uses the gu to get some work done in parallel with the cpu

TH_B:
the second thread output frames at the correct timing (with a simple sceDisplaySetFrameBuf)


the situation is something like:


TH_A:

loop:
{
wait the "i can put in the ring buffer" semaphore

generate a frame in the buffer

signal the "i can get from the ring buffer" semaphore
}


TH_B:

loop:
{
wait the "i can get from the ring buffer" semaphore

sceDisplaySetFrameBuf

signal the "i can put in the ring buffer" semaphore
(not done for the very first frame since the buffer is really reusable only from the second loop iteration)
}


TH_A priority is lower than TH_B priority.


and now the problem:

randomly TH_B seems to freeze.
some things i've noticed:

- seems to not happen when the cpu is at 333mhz
- seems to not happen if i eliminate the gu in the process
- seems to not happen if i give TH_A the same priority of TH_B


i really don't have idea of what happen (i could move the gu code in TH_B but this require a lot of tweaks and will be a suboptimal solution)

[jonny]

some progress:

TH_B also output audio with sceAudioOutputBlocking
this seems the function that freeze
if i change it to sceAudioOutput, i start getting silence (where previously i had the freeze - sceAudioOutput return 0x80260002)
so ... seems a sort of collapse of the psp audio system ...


another interesting thing:

TH_A uses the GU, during the process i use sceGuCopyImage to copy data from vram to system memory
if i comment this sceGuCopyImage, all seems to work correctly


someone see a relation in the 2 operations?

if someone want to check, i can post the code.

[ReKleSS]

There's one thing that comes to mind here, looking at your code - do you realize that the psp uses cooperative multithreading, and are you accounting for it? If yes, you can ignore the rest of what I have to say.

The psp won't take control away from your threads - you have to give it up. There are a few GU functions that will do so, so that your other threads can do stuff while the GU does whatever you told it to. sceKernelDelayThread(0) should make a thread yield; sceKernelSleepThread() may do the same thing, but I'm not sure.

[jonny]

There's one thing that comes to mind here, looking at your code - do you realize that the psp uses cooperative multithreading, and are you accounting for it?

at the start, i was thinking about a similar problem, i have filled the code with many sceKernelDelayThread in both threads (even if the initial code should be already ok)
but this haven't solved


after a deep look, sceAudioOutputBlocking is the function that freeze the thread
the app runs normally for a bit, with correct audio and video output, but after some time it freeze (always at the same point)

- commenting sceAudioOutputBlocking eliminate the freeze
- changing sceAudioOutputBlocking to sceAudioOutput no more freeze the app (but i get silence after i surpass the point where i previously had the freeze)

so, seems that something in the audio system gets ruined