Emulator

I think there might also be missing sound effects in Action Replay Max (v1.14). When navigating the menus, I do hear a click sound, and "Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 80 blocks from 0x015894a0" is logged. However, selecting "Action Replay Codes" in the menu logs "Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 823 blocks from 0x0158a0a0" without any sound, and pressing B on that screen logs "Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 1828 blocks from 0x0158a0a0". I found a video of a (probably older) version, and there is an additional sound when opening the menu at least.

Also, since I reported this issue, the message has changed slightly; it's now logging a physical address (starting with 0x0) instead of a virtual one (starting with 0x8). I'm not sure why that's happened. Here's the new one from MaxPlay: "Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 731 blocks from 0x002ba7e0"

One other thing to note is that the relevant sound is present in memory at the logged address; this can be confirmed by dumping MRAM and then importing the dump into Audacity as signed 16-bit PCM, big endian, 1 channel, with the offset set based on the logged value in converted to decimal (e.g. 0x015894a0 becomes 22582432, and 0x002ba7e0 becomes 2861024) and the sample rate set to 32000. You can at least hear something that seems relevant. Note that the stuff afterwards may be random contents of main memory, which will generally result in loud and painful sounds when played back as audio, so be careful.

I did also test out the GameCube IPL, which logs "Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 70 blocks from 0x014e5c20". Dumping MRAM and then using offset 21912608 shows that a short bit of audio is in memory at that location, but it doesn't store the whole intro sound there at the same time. The same does apply to maxplay; as it runs, it is loading new data into 0x002ba7e0 (which clarifies something I was confused about; it did seem like the audio was longer than just the bit that can fix into that location. It just doesn't need to reconfigure the audio DMA (or the way we're logging that message means it doesn't get shown again)).

A discovery: the music for MaxPlay and the sound effects from AR Max is dumped properly when using Movie → Dump Audio! The AR Max sound effects seem to get played twice in a row, but otherwise they sound correct. So, the issue is happening somewhere in the mixing process (which is not applied to the dumped audio). It doesn't seem to be a volume issue either - the volume registers seem to be 256, and although volume isn't used when dumping (#12945), there's no difference in the dumped audio with PR 10735 which fixes that.

I've determined the cause: Datel is sending too many samples at once, so the buffer in Mixer.cpp (currently 4096 stereo samples) is too small and thus never gets populated. Here's a basic fix: https://github.com/dolphin-emu/dolphin/pull/10738

1 audio DMA block is 8 stereo samples, which is sixteen 16-bit words, or 32 bytes. So, at 32000 Hz, MaxPlay's 731 blocks is 5848 stereo samples per transfer, or 0.18275 seconds of audio per transfer, which is a lot but works out because they're not generating it on the fly from the DSP (as far as I can tell). AR Max's 1828 blocks is 14624 stereo samples, or 0.457 seconds. And, the The Wii-compatible action replay logs "Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 2298 blocks from 0x00f19ba0". 2298 blocks is 18384 stereo samples, or 0.5745 seconds, which is enough to break the audio dumping code.

Note that even with the fix, sometimes Datel's sound effects play twice. I'm not sure why that happens.