Changing drivers of a bluetooth headset during a webrtc call can still cause video delays remotely
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox85 | --- | fixed |
People
(Reporter: pehrsons, Assigned: pehrsons)
References
Details
Attachments
(17 files, 2 obsolete files)
83.75 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
After bug 1586370 this was meant to be fixed. It appears to still occur.
I think bug 1586370 laid out the groundwork, and something silly remains.
STR:
- On a different machine, start a webrtc call (I used whereby.com with 4 remote peers on the same machine, 1 might work too).
MOZ_LOG=raw,AudioCallbackTracing:5 MOZ_LOG_FILE=$SOMEFILE ./mach run
- Join the webrtc call.
- Change device in the application's UI if it provides one (this should be fine from bug 1601034). Change to a bluetooth mic (on mac) for full effect.
- Mute the mic, and ensure that the mic is turned off per the permissions UI in the address bar.
- Unmute the mic. Mute. Unmute. Mute. Unmute.
- Close the tab, the browser, the browser on the other machine.
- Load the relevant log file (with content) with $SOMEFILE prefix in Chrome's
chrome://tracing
.
Expected: Graph is iterated continuously throughout the call.
Actual: See attachment (4s freeze).
Comment 1•6 years ago
|
||
I ended up disabling test_mediarecorder_pause_resume_video.html for debug OS X in Bug 1605150, please have a look at re-enabling it as part of this bug.
Comment 2•6 years ago
|
||
I've talked with alex he will have a quick look on this.
Comment 3•6 years ago
|
||
I have been trying reproducing it in Linux with no success. I am using a bluetooth handsfree and I am able to see in the logs the ThreadedDriver
thread starting and stopping as expected. Also, I don't experience any A/V lag. I have tested with a debug build and an opt build. Thus, I believe it is something specific to OSX. Next, I will try reproducing in OSX.
Comment 4•6 years ago
|
||
In OSX this error can be reproduced easily. It happens in every unmute when the AudioCallbackDriver is switching from output only to duplex. Even if the delay is not as much as 4 secs, which reported in the description, it is about 1.5 secs, which is long enough for real-time communication.
Looking at the code, AudioStreamState is set to pending when the driver starts and becomes Running
in StateChangeCallback when the state is CUBEB_STREAM_STARTED. The device is supposed to start right after that callback. However, a Bluetooth device in OSX must not start immediately and thus the delay occurs.
I am working on a patch that will keep the value of AudioStreamState to pending till the first audio callback. That seems to overcome the issue. Initial testing looks promising.
Comment 5•6 years ago
|
||
On an AudioCallback driver switch, a Fallback driver operates to run the graph during the switch. The fallback driver is stopped when the AudioCallbackDriver::StateCallback
reports the started state. A device is supposed to start right after the start callback but in OSX, bluetooth devices can take several hundred milliseconds until the first audio callback arrives.
With this change, the fallback driver is kept alive until the first audio callback. On first audio callback the Fallback driver is being requested to stop and silence is returned. Fallback driver, in the next iteration, will run the graph for last time and stop itself.
Comment 6•6 years ago
•
|
||
Assignee | ||
Updated•5 years ago
|
Comment 7•5 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:pehrsons, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D97309
Assignee | ||
Comment 10•5 years ago
|
||
Assignee | ||
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
StateComputedEnd was likely a typo back in the day. The member in the graph is
mStateComputedTime, so let's center around that.
Assignee | ||
Comment 13•5 years ago
|
||
This allows re-using them in TestAudioCallbackDriver.cpp.
Assignee | ||
Comment 14•5 years ago
|
||
Filling the output buffer, even if only with silence, is needed for the audio
driver to iterate with the right number of frames. This patch makes sure the
graph always does this.
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
|
||
Feeding the mixer is needed for AudioCallbackDriver to properly bookkeep how far
to iterate the graph, relative to how many frames are fed from the data
callback.
Assignee | ||
Comment 17•5 years ago
|
||
Assignee | ||
Comment 18•5 years ago
|
||
The existing FramesProcessedEvent will only be notified if there is an
AudioVerifier attached. FramesGeneratedEvent can be used to see how much audio
a MockCubebStream has generated without the verifier.
Assignee | ||
Comment 19•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 20•5 years ago
|
||
Updated•5 years ago
|
Comment 21•5 years ago
|
||
Assignee | ||
Comment 22•5 years ago
|
||
D97403 got overtaken the gtest for AudioInputTrackDisabling. This fixes the
bustage that combination resulted in.
Comment 23•5 years ago
|
||
Comment 24•5 years ago
|
||
Backed out for GTest failures on TestAudioTrackGraph
Backout link: https://hg.mozilla.org/integration/autoland/rev/c1966d168b33b8ea005418d5564e2b414bb535a9
Log link: https://treeherder.mozilla.org/logviewer?job_id=322336552&repo=autoland&lineNumber=29579
Comment 25•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 26•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 27•5 years ago
|
||
0 ticks is fine, and happens often for graphs with a low sample rate because in
such cases the minimum 128-frame AudioBlock is rather large and spans multiple
iterations.
Assignee | ||
Comment 28•5 years ago
|
||
These MediaTrack used to subclass ForwardedInputTrack and that module is
legacy from that time. MediaTrackGraph makes more sense. We should reduce the
number of log modules around the graph and converge on the MTG one.
Assignee | ||
Comment 29•5 years ago
|
||
Comment 30•5 years ago
|
||
Comment 31•5 years ago
|
||
Comment 32•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4dedf07fafcf
https://hg.mozilla.org/mozilla-central/rev/29edda566e71
https://hg.mozilla.org/mozilla-central/rev/357b00e7a051
https://hg.mozilla.org/mozilla-central/rev/f8b9c0181a32
https://hg.mozilla.org/mozilla-central/rev/74a6757be69d
https://hg.mozilla.org/mozilla-central/rev/949487b6a742
https://hg.mozilla.org/mozilla-central/rev/2e5dd044dfd2
https://hg.mozilla.org/mozilla-central/rev/cfc115ee98c2
https://hg.mozilla.org/mozilla-central/rev/af228160e8ea
https://hg.mozilla.org/mozilla-central/rev/863b74ef8e70
https://hg.mozilla.org/mozilla-central/rev/91a6ec380d44
https://hg.mozilla.org/mozilla-central/rev/8c14bf385506
https://hg.mozilla.org/mozilla-central/rev/852e2eac194a
https://hg.mozilla.org/mozilla-central/rev/7b0249b51e04
https://hg.mozilla.org/mozilla-central/rev/763abca071e0
https://hg.mozilla.org/mozilla-central/rev/fcd809baf4c6
Description
•