Fix audio thread registration in AudioStream.cpp
Categories
(Core :: Audio/Video: MediaStreamGraph, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox79 | --- | fixed |
People
(Reporter: padenot, Assigned: padenot)
References
(Regressed 2 open bugs)
Details
Attachments
(1 file)
Same deal.
|
Assignee | |
Comment 1•4 years ago
|
||
More or less the same as GraphDriver.cpp but simpler because there is only one
return statement.
|
||
Updated•4 years ago
|
Pushed by padenot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/953d224e37c4 Fix audio thread registration to the profiler in AudioStream.cpp. r=achronop
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
This seemed to introduce a regression in recent version of Firefox. My attempts to workaround the problem is in https://reviews.freebsd.org/D26303
The change in this ticket tries to profile the audio threads created by libcubeb. However, for some of the backends at least, such as sndio and sun and even pulse in my test setup,
the code here would not unregister the NativeAudioCallback from audio thread registry whenever the audio stream is paused. When that happens,
the RegisteredThread would remain in CorePS::RegisteredThreads. After that, if another thread is created, and reusing the same thread ID, it will
reuse the existing RegisteredThread without initializing the TLSRegisteredThread pointer to the existing RegisteredThread. This later will fail the
following lines in profiler_unregister_thread():
MOZ_RELEASE_ASSERT(registeredThread ==
TLSRegisteredThread::RegisteredThread(lock));
When constructing a fix to the problem, I think it is better to allow launching a callback when the audio threads are to be stopped. This may require either libcubeb having a new API for such purpose , or at least receiving notification somewhere in AudioStream.
Description
•