Emulator

It has been suggested that this is an integer rounding issue, where the actual sample rate of 54000000/1124 (for 48khz) is not properly represented by our integer timing values.

This is correct-ish. The issue here is that by rounding off 54000000 / 1124 (48khz) and 54000000 / 1124 / 1.5 (32khz) to integer values (48043hz and 32029hz) instead of their proper values, you end up getting an uneven number of cycles per sample.

https://github.com/dolphin-emu/dolphin/blob/d32b13fb36e6616f7bb4a5a395c34ae2f2ada32b/Source/Core/Core/HW/SystemTimers.cpp#L113
This is the relevant timing code. It expects a constant number of cycles per sample, doing math with the CPU clock rate and such to figure that out. The divisions do not divide evenly, causing rounding errors and the actual output sample rate to be around 32024.2hz/48061.7hz.

Using the correct sample rates would be the optimal solution. This would be accurate to hardware and have a nice clean cycles per sample. Audio mixing code and audio dumping code would only need to be reworked to handle the non-integer sample rate. Audio mixing code actually seems to use floats anyways for resampling (https://github.com/dolphin-emu/dolphin/blob/f96e91119accffe1bed892a6419580cffbcec099/Source/Core/AudioCommon/Mixer.cpp#L97), so not much change there. Audio dumping code is more problematic, as wav doesn't seem to support non-integer sample rates. That would need to be reworked into another format that supports such. Or alternatively, the audio could be resampled to a clean integer sample rate (and maybe at that point mix dsp and dtk together into one wav file and avoid splits altogether).

The above pull request was merged in the following version, however I have not tested this fix.

5.0-16788 -> https://dolphin-emu.org/download/dev/de3d1344d5ed939faedae9c19e2e340a83038aba/

Technically it's not entirely fixed, but it's going to be difficult to get it better without resampling the audio.