#129879 - TheChuckster - Mon May 28, 2007 4:59 pm
I finally managed to get sound streaming to work on the DS, but the callback function that generates the audio (via emulation of the Atari 2600 TIA chip) is not interrupt safe.
I am not quite sure why it is not interrupt safe. What makes a function "interrupt safe"?
I do know that if I put that function within an interrupt, the DS locks up.
I tried using a "semaphore" global variable that would tell the emulator to generate (x) sound samples during the next frame into buffer (y) for the sound streaming, but that is too slow.
I even tried moving the emulator loop into the interrupt code itself (just as a test to satisfy my curiosity). The DS still crashed. Apparently, even if the emulator loop is executed "in sequence" inside the interrupt, it still crashes. Even though the only difference is that it is being called inside an interrupt.
Which leads me to my next question, can another interrupt interrupt an interrupt in progress? Maybe that's screwing things up...
Is there a way to work around this? I brainstormed a bit and thought of using filling up a secondary buffer during emulation, and then just having the callback function use that. I'm not sure if that would work, but it would be challenging to know the position of the "sound cursor" within that secondary buffer.
How have other developers accomplished this? It might just be easier for me to identify what is making the TIA update function "interrupt unsafe". What should I be looking for?
I am not quite sure why it is not interrupt safe. What makes a function "interrupt safe"?
I do know that if I put that function within an interrupt, the DS locks up.
I tried using a "semaphore" global variable that would tell the emulator to generate (x) sound samples during the next frame into buffer (y) for the sound streaming, but that is too slow.
I even tried moving the emulator loop into the interrupt code itself (just as a test to satisfy my curiosity). The DS still crashed. Apparently, even if the emulator loop is executed "in sequence" inside the interrupt, it still crashes. Even though the only difference is that it is being called inside an interrupt.
Which leads me to my next question, can another interrupt interrupt an interrupt in progress? Maybe that's screwing things up...
Is there a way to work around this? I brainstormed a bit and thought of using filling up a secondary buffer during emulation, and then just having the callback function use that. I'm not sure if that would work, but it would be challenging to know the position of the "sound cursor" within that secondary buffer.
How have other developers accomplished this? It might just be easier for me to identify what is making the TIA update function "interrupt unsafe". What should I be looking for?