![]() The relevant part of the stack traces is: thread #1, name = 'SYNTH.APP', queue = '-thread' I have noted that the is always a call to audioCallback with “ audioDeviceStopPending=1” just before the deadlock happens. Locking audioCallback() ! thread=0x16bedf000 audioDeviceStopPending=0 Returning after AudioDeviceStop() at audioCallback() Locking audioCallback() ! thread=0x16bedf000 audioDeviceStopPending=1 Locking at stop(), leaveInterruptRunning=0 Locking at stop(), leaveInterruptRunning=1 ![]() Locking audioCallback()! thread=0x16bedf000 audioDeviceStopPending=0 Locking audioCallback! thread=0x16bedf000 audioDeviceStopPending=0 Here is a trace of the last events before the deadlock: locking audioCallback() ! thread=0x16bedf000 audioDeviceStopPending=0 It seems that the audioCallback() is called while AudioDeviceStart() is being executed, and AudioDeviceStart() waits for audioCallback to complete, but audioCallback cannot complete because it can’t lock callbackLock… At some point the ‘ callbackLock’ mutex of juce_mac_CoreAudio.cpp is locked by both the audioCallback() and the start() member functions, and none of them progresses anymore. The deadlock happens on my mac mini M1, but not on my macbook 2016 running catalina.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |