[Emulator] MACPTR to VERA causes poor performance

[Ed Minchau]

Yeah, the PCM FIFO should only be empty after it plays the last sample. Once it gets down to 1024 bytes in the FIFO and triggers AFLOW, at 12970 Hz 16 bit that's about 0.04 seconds worth of data still in the FIFO. Then, pushing data from where it was loaded to in VRAM into the FIFO only takes about 33000 cycles or 0.004125 seconds. So, by the time a new 1/10th of a second of audio is loaded there should still be about 0.035 seconds of older audio data in the buffer.

[MooingLemur]

This might actually be a different issue. The demo might be getting confused when the PCM fifo becomes 0, because that's when the glitches happen. If I remove the code which skips clockticks6502 forward after an intercepted IEEE call, the demo no longer glitches.

I think this is a case of MACPTR just being slower on my machine, and the fact that the 6502 can't service IRQs during that time. That might be causing a situation the demo normally doesn't have to deal with, like the PCM fifo having a chance to become empty.

It is certainly possible in this scenario that the audio fifo gets starved. While catching up, all of the individual components are stepped fully and are caught up before IRQ has a chance to fire, which could be thousands of clocks past the point where IRQ would have been asserted. Think of it as hostfs being like a DMA card that takes over the bus, halts the CPU, and populates memory before letting the CPU continue. This could certainly glitch demos which depend on strict timing.

If I reduce the number of bytes MACPTR returns, the demo glitches similarly, probably for a related reason, in the sense that the demo is expecting to fill more of the FIFO with the fruits of each MACPTR call, and it ends up emptying.