Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
5.9, 5.15.12, 6.2.6
-
None
-
macOS 13.0, 13.1, 13.2
-
-
919b3d308 (dev), ff5d7e0c1 (6.5), a16dd3377 (6.5.0), 03a44e5a6 (6.4), 83f646723 (tqtc/lts-6.2), d2b4d94ae (dev), f7b737610 (6.5), 202c64edc (6.6)
Description
Our application has been freezing for some users on macOS 13.
I was able to get the user to grab a process sample, which I will attach.
It shows the main thread calling CoreAudioOuput::start, which calls AudioOutputUnitStart, and is stuck holding a lock.
You can also see the "com.apple.audio.IOThread.client" thread has called AudioOutputUnitStop from the renderCallback, and it is holding a different lock.
I was able to duplicate this across three versions of Qt.
In this use case, our application starts and stops audio playback frequently. However, we've never had reports of this hang until recently.
It is supposed to be that if you call AudioOutputUnitStop from the I/O callback, the I/O callback should not be called again until it is restarted. However, I think that macOS 13 has broken this.
In any case, the issue can be fixed by ensuring that AudioOutputUnitStart and AudioOutputUnitStop cannot be called at the same time.
I added a sample application that demonstrates the issue.