AudioTransportSource isn't threadsafe

There are several data races in this class, mainly with the getNextReadPosition() member function.
There are also some sendChangeMessage calls from inside getNextAudioBlock()

I migrated the JUCE AudioFilePlayerDemo project into a plugin and Xcode flags several data races in the code.

You can test it out here:

the AudioFilePlayerDemo project that comes with JUCE uses the AudioTransportSource to handle all of the playback duties of audio files.

2 Likes

In the plain AudioPlaybackDemo, I can only trigger a single race on inputStreamEOF, and I’ve merged a fix here:

Would you mind testing out the AudioFilePlayer repo?
the Master branch contains the latest changes.
This should trigger the thread sanitizer issues and also demonstrate those sendChangeMessage() calls from the audio thread. Those calls are written in the JUCE class, not my code.

I did test out your demo, I think I got it passing thread sanitizer on develop. If I missed something, please let me know what steps you’re taking to trigger the issue and I’ll take another look.

That seems to have solved it when I test with Audio Plugin Host.

Any thoughts on the calls to ‘sendChangeMessage()’ happening in getNextAudioBlock()? that function is called from the audio thread.

It’s not ideal, but it also seems like it’s fit for purpose. That code has been in place for at least a decade, and it doesn’t seem to be causing issues for people.

Sure, but it locks and allocates when the Change Message is added to the MessageManager queue.
Locking and allocating on the audio thread are no-no’s unless the rules have changed…