Closed banjerluke closed 2 years ago
This is the only related thread I could find on StackOverflow:
Only I'm already on the main thread (DispatchQueue.main.async
)...
It appears that this was caused by this:
self.player.play(from: offset, to: nil, at: time, completionCallbackType: .dataRendered)
^^^^^^^^^^^^^
I changed completionCallbackType
back to .dataPlayedBack
and it doesn't deadlock anymore. There are definitely still problems but I'll open new issue(s) for them.
Important preface: I went back to using a pool of AudioPlayer objects that are all instantiated before the engine is started; that fixed random engine-related errors I was getting, and also eliminated the overhead of creating new AudioPlayer objects all the time. As a bonus, I can now easily reuse buffered players for repeated samples! In
master
, each Channel has its own pool of AudioPlayer/SamplePlayer objects; I am experimenting with using a shared pool of AudioPlayers (in thedev/unified-pool
branch) but that has no bearing on this issue...If you hit "Play Drum Loop" and wait awhile (10-30 seconds usually), eventually it will stop responding. If then I pause execution, it's always inside
__psynch_mutexwait
:This is originating from
[AVAudioPlayerNode stop]
, which is being called byAudioPlayer.stop()
– sometimes because it's called directly, sometimes as part of a call to.load()
or.play()
. It seems like there's a small chance of that function deadlocking anytime it's called... which is obviously far from ideal!Happens in both iOS 15 and iOS 14.4 simulators as well as my real iPhone.