Open
Bug 1393572
Opened 8 years ago
Updated 1 year ago
When starting a webrtc call, audio already playing in other tabs or applications breaks
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Core
WebRTC: Audio/Video
Tracking
()
NEW
People
(Reporter: ng, Unassigned)
Details
When starting a webrtc session[0] in a tab (Tab A) while audio is playing[1][2] in another tab (Tab B), the audio from the call works fine, but the audio from Tab B loops a small sample. If I close Tab A, the other tab stops playing audio. If I then start another call (Tab C), the same loop will begin playing again. This continues until I close Tab B.
If I start audio in Tab B after starting a webrtc call, everything works as expected.
[0] https://jsfiddle.net/jib1/qs830j4j/
[1] https://freemusicarchive.org/
[2] https://soundcloud.com/
| Reporter | ||
Comment 1•8 years ago
|
||
This was observed on macOS Sierra 10.12.6 using Nightly.
Version 57.0a1
Build ID 20170824100243
| Reporter | ||
Comment 2•8 years ago
|
||
After using mozregression I have not been able to reproduce this.
Priority: P1 → --
| Reporter | ||
Comment 3•8 years ago
|
||
A couple of notes:
It is not limited to other tabs. This happens when I play audio in VLC.
I can't seem to get it to happen when using my standard MOZ_LOG settings. Given this, I am attempting again to find a regression range.
Summary: When starting a webrtc call, audio already playing in other tabs break → When starting a webrtc call, audio already playing in other tabs or applications breaks
| Reporter | ||
Comment 4•8 years ago
|
||
10:29.93 INFO: Narrowed inbound regression window from [e4d9cb33, acb1bd24] (3 builds) to [219ca191, acb1bd24] (2 builds) (~1 steps left)
10:29.93 INFO: No more inbound revisions, bisection finished.
10:29.93 INFO: Last good revision: 219ca1919e9b96af351978d00366176ae507304a
10:29.93 INFO: First bad revision: acb1bd24c64d2f24e87930bcff4bace242d1d3a8
10:29.93 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=219ca1919e9b96af351978d00366176ae507304a&tochange=acb1bd24c64d2f24e87930bcff4bace242d1d3a8
This range includes Bug 1381015, which seems like a likely candidate.
CCing Alex.
Comment 5•8 years ago
|
||
Thanks for the description Nico, I will try to repro here.
Flags: needinfo?(achronop)
Updated•8 years ago
|
Rank: 15
Priority: -- → P1
Comment 6•8 years ago
|
||
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Comment 7•8 years ago
|
||
Hi Nico, if I remember well we couldn't repro this in Austin. Can you please try once again, when you can, and tell me if this is still an issue. Thanks.
Flags: needinfo?(achronop)
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Priority: P2 → P3
You need to log in
before you can comment on or make changes to this bug.
Description
•