Apologies for taking a while to respond to this, I wanted to get the rest of the team’s input before making any changes.
The original forum thread that lead to this change was here:
and the “fix” that I pushed was to make the AudioBuffer::isClear flag atomic which silenced tsan but clearly had some unintended side effects.
Given that AudioBuffer makes no guarantees about thread safety and contains no other synchronisation I don’t think it should be the responsibility of the class to be thread safe. Making isClear atomic also doesn’t make it thread safe since some higher level synchronisation would be required to actually guard the clearing and filling of the audio data, it just makes tsan happy.
I’ve reverted that change and made isClear a plain old bool here:
and I’ve pushed a fix for the actual problem in BufferingAudioSource here: