I’ve spent the whole day trying to track down why MP3 playback has become stuttery and finally tracked it down to this commit:
I can’t quite see what the commit was intending to fix but I think the stuttering was introduced with this line:
auto startPos = ((pos - 1024) / samplesPerBlock) * samplesPerBlock;
The JUCE and Windows MP3 reading can’t skip to arbitrary sample positions. I think the JUCE reader needs a few hundred samples to get going but the WindowsAudio reader is worse, it seems to quantise to a few ms. The CoreAudioReader seems to figure this out behind the scenes so it’s not a problem on macOS.
I imagine what the
- 1024 above does is ensure the start position of the block has enough time to properly produce samples.
Is it possible to fix this or revert the change?
One of the main uses for BufferingAudioReader is to decompress files on a background thread i.e. be used in conjunction with MP3s so it really needs to work with that.