Going back to that DSP issue - now, after a few more hours of tests, I'm pretty much convinced this isn't about DSP but rather ADPCM. See, the DSP works just fine with 8- and 16-bit samples being input: - it works for Saturn tunes - it breaks only certain Dreamcast tunes - hissing/clipping only occurs when ADPCM samples are being routed through DSP
All DSP does (in short) is take the input wave, modify it a bit and add it back time-shifted. However if the output saturates and stays like that it will distort or even mute all sounds during final mixing pass. Non-ADPCM samples eventually integrate to zero, so the adder never overflows. But ADPCM samples seem to have a bias and tend to dive into negative numbers and stay there (loop jumps recover a bit, but not completly). And it's exactly what upsets the DSP - you can test that by inverting the sign of ADPCM samples being written to MIXS. It will create exactly the same output wave but mirrored around time axis. Reducing ADPCM dynamic range (from -/+ 32768 to let's say 24000) helps, but you can still see the output swinging rather then being symmetric.
I'm trying to figure out what's wrong with the decoder and why does it introduce the bias, but not much luck so far. Maybe I'm missing something obvious? kingshriek, if you have some time could you please look into that as well? All you need to do is extract some raw ADPCM data and convert it to WAV, then view it under some sound editor like Audacity. You should see the problem right away. You can use soa-367-04-00.minidsf as it starts with ADPCM and exibits the symptoms. I can provide you with longer streams if you want - dialog lines from Soul Reaver. It's very obvious on those: http://pics.livejournal.com/dknute/pic/000eky4b
EDIT: Well, I haven't found this to be a problem in a while... anyway - shifting is the culprit. -1 >> 3 is still -1, whereas -1 / 8 is zero. It's consistent with the fact that the bias is towards negative values. I'll see if +1 trick will work and test it further and get back to you
