This BMO bug was random crashes during calls, mostly when using a bluetooth device.
The cause of this bug was because when an error happened, the backend didn't wait for the streams to be stopped before firing the state callback.
AAudioStream_requestStop simply requests the stream to stop (as the name implies), and the buffers are flushes before the stream stops. If the stream is outputing to a bluetooth device, the long buffer makes it more likely for a data callback to fire, apparently, and we were in a situation where the cubeb user thought the stream was in error, but a data callback was fired after the error callback being called. In practice, Firefox's recovery logic had kicked in, and the data callback was calling at the same time into the graph as some other code, wrecking havoc.
The 4th patch here is the fix, the code now just wait that the aaudio streams are stopped before firing the error callback.
An assert is also added to ensure this is doing the right thing.
This BMO bug was random crashes during calls, mostly when using a bluetooth device.
The cause of this bug was because when an error happened, the backend didn't wait for the streams to be stopped before firing the state callback.
AAudioStream_requestStopsimply requests the stream to stop (as the name implies), and the buffers are flushes before the stream stops. If the stream is outputing to a bluetooth device, the long buffer makes it more likely for a data callback to fire, apparently, and we were in a situation where the cubeb user thought the stream was in error, but a data callback was fired after the error callback being called. In practice, Firefox's recovery logic had kicked in, and the data callback was calling at the same time into the graph as some other code, wrecking havoc.The 4th patch here is the fix, the code now just wait that the aaudio streams are stopped before firing the error callback.
An assert is also added to ensure this is doing the right thing.