I've been trying to work out the intended threading model is when using drowaudio AudioFilePlayer / AudioFilePlayerExt?
From what I've been able to work out:
- drowaudio is in various ways not threadsafe to use in a way that one is creating or calling functions (such as setPosition) on AudioFilePlayer / AudioFilePlayerExt objects outside the critical audio thread (i.e. in a different thread than the one that calls getNextAudioBlock). I've found multiple ways in which it is not threadsafe (causing asserts+crashes-etc) for such a use-case, and making it threadsafe is not possible 'from the outside' as it were.
- A MessageManager lock is required in order to create AudioFilePlayer objects (when AudioFilePlayer::commonInitialise() calls audioTransportSource.addChangeListener(this)) - this means that one is forced to acquire a MessageManager lock in this critical audio thread - obviously not a desirable thing to be doing (and also currently causing a deadlock for me on shutdown when it tries to stop the audio if it's in the process of starting some file playback inside the audio thread, tho I'll likely find some way to work around that).
Note, I haven't upgraded to juce 4 yet - I'd be curious whether there's any improvements in juce 4 to any such audio / threading-related areas? i.e. one potential fix for the above and something that would be generally preferable, is that changeListeners could be made internally threadsafe and thus not requiring any global MessageManager lock for them at least, thus no global lock would be required to add a changeListener to a ChangeBroadcaster.