Hi Nicolas.
I found the cause for the sound problem, it's related to the change
I made to pass a more accurate cycle count to DSP_Run. Unfortunately
it can't work at the moment until 68030 cycles are more accurate in
Hatari (by taking into account bus access time, as it's already the
case for 68000 STF mode).
Basically it made the DSP runs for many more cycles than what the
CPU ran, causing some sync problem between DSP/CPU.
I will revert the change to still get some sound in the meantime.
Good news that you found the cause! I do find it a little strange though
- because I don't use the DSP for audio. In my case, if the DSP/CPU get
out of sync the program will lock because they are used synchronously.
This is exactly what happens in testing if I make a mistake with the
synchronous pattern. There are no timecritical mistakes possible without
'program death'. There is no non-determinism in this respect.
So why CPU/DSP timing would affect codec output is unclear. Of course it
could be affecting things earlier in the sequence - in the TOS crossbar
init code or TOS boot sequence. Then it could begin to make more sense
maybe... still odd though as TOS code should always synchronize
explicitly (unlike me) and not care about actual performance of any device.