I suspect the issue is that the audio system normally free wheels a little on the real hardware, it runs really close to 48k, but might not be spot on. Hence i think the audio interface includes the sample counter, and an interrupt when it passes a particular point.
While it requests a 48k output reality is that the timing is probably not precisely 48k, it's just really close. (as getting bang on accurate 48k is unlikely to be cheap)
So the backlog probably varies, IE you might get 47990hz, and it backs up 10 samples a second. Some may have one a little quicker, eg 48010 and end up not having enough samples.
If the real hardware works as I suspect, it uses the AI interrupt to trigger a request to the DSP to make new audio, which then ends up in the AI fifo, and that feeds into samples being consumed, which then triggers the next AI interrupt to get more data.
I'll have to do more digging, but my suspicion is the idea of the audio should be that it runs at the speed of the output clock.
I want to do some digging to work out what the AI interrupt actually does in game code, IE is it a trigger to push the next command at the dsp? And what the AI interrupt counter tends to get updated to, is it one frame of samples...
Of course I admit this is perhaps a naive view of the emulation.
Note I'm not saying it should be async to the cpu (as the HLE-zelda shows that async is different mess), just that the engine shouldn't bang out audio even if there's nothing to consume it. It might also be the cause of the audio lag that people have reported (in another thread) as the current mixer buffer is 8k samples (250ms @32khz)
Of course this could be a subtle bug hiding somewhere in the output path, but the buffer does fill up...
While it requests a 48k output reality is that the timing is probably not precisely 48k, it's just really close. (as getting bang on accurate 48k is unlikely to be cheap)
So the backlog probably varies, IE you might get 47990hz, and it backs up 10 samples a second. Some may have one a little quicker, eg 48010 and end up not having enough samples.
If the real hardware works as I suspect, it uses the AI interrupt to trigger a request to the DSP to make new audio, which then ends up in the AI fifo, and that feeds into samples being consumed, which then triggers the next AI interrupt to get more data.
I'll have to do more digging, but my suspicion is the idea of the audio should be that it runs at the speed of the output clock.
I want to do some digging to work out what the AI interrupt actually does in game code, IE is it a trigger to push the next command at the dsp? And what the AI interrupt counter tends to get updated to, is it one frame of samples...
Of course I admit this is perhaps a naive view of the emulation.
Note I'm not saying it should be async to the cpu (as the HLE-zelda shows that async is different mess), just that the engine shouldn't bang out audio even if there's nothing to consume it. It might also be the cause of the audio lag that people have reported (in another thread) as the current mixer buffer is 8k samples (250ms @32khz)
Of course this could be a subtle bug hiding somewhere in the output path, but the buffer does fill up...