No longer able to send stereo audio when setting fmtp stereo=1 in the sdp

VERIFIED FIXED in Firefox 66

Status

()

P1
normal
VERIFIED FIXED
2 months ago
20 days ago

People

(Reporter: adam, Assigned: drno)

Tracking

({regression})

65 Branch
mozilla67
Desktop
All
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox65 wontfix, firefox66+ verified, firefox67 verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 months ago

As of Firefox 65 stereo audio has stopped working for us with TokBox/OpenTok.

Steps to reproduce:

  1. Open https://opentok.github.io/opentok-web-samples/Stereo-Audio/ in 2 tabs
  2. Click the Publish button when it appears in one of the tabs
  3. You should now hear a funky guitar riff 🎸🎵
  4. Use the slider to adjust the pan value left and right

Expected Result: You should hear the audio move from the left side to the right side of your speakers. This works in Firefox 64 and below.

Actual Result: The audio does not pan left and right.

To do this we are modifying the SDP offer like so:

a=fmtp:109 maxplaybackrate=48000;useinbandfec=1; sprop-stereo=1

and the answer like so:

a=fmtp:109 useinbandfec=1; stereo=1

(Assignee)

Updated

2 months ago
Assignee: nobody → drno
Priority: -- → P1
(Assignee)

Updated

2 months ago
status-firefox65: --- → affected
status-firefox66: --- → affected
status-firefox67: --- → affected
status-firefox-esr60: --- → unaffected
Depends on: 1376873
Keywords: regression
OS: macOS → All

Comment 4

2 months ago
Pushed by nohlmeier@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8f854b755c2d
set Opus stereo on send stream with 2 channels. r=dminor
(Assignee)

Comment 5

2 months ago

[Tracking Requested - why for this release]: This is a bad regression as stereo audio over WebRTC is no longer working any more. We don't know how often stereo audio is used in the field. But we should try to get this fixed as soon as possible (assuming it's too late for 65).

tracking-firefox66: --- → ?

Comment 6

2 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 2 months ago
status-firefox67: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Let's verify and then aim to uplift this to beta 66.

tracking-firefox66: ? → +
Flags: qe-verify+

Comment 8

2 months ago

I can confirm that the audio move from the left side to the right side of the speakers once I use the slider to adjust the pan value left and right on Firefox Nightly 67.0a1 (2019-02-04) on Windows 10 x 64, Windows 7 x32, Mac OS X 10.14 and on Ubuntu 16.04 x64.

But the sound only works after I clicked on "Publish" on both tabs not just on one of them like what was mentioned above, and the sound was controlled from the second tab I published but was heard from the first tab, so am not sure about the steps above and what is the correct behavior in this case.

I compared what happening on chrome also and there I only had to click publish on one tab, and unmute the other one, and the sound was controlled form the tab which was published.

Could you please confirm if these are the expected behavior or not?
Thanks.

Flags: needinfo?(drno)
(Assignee)

Comment 9

2 months ago

I keep seeing "Error: MediaDecodeAudioDataInvalidContent" now if I click in Nightly 2019-02-04. But I think that looks like some kind of race condition in the test pages JS code to me.

How many times you have to click on the demo page is not important for the verification of this. Important is that once you are connected and see the slider for panning you can hear the audio panning between both sides (which is not the case in 66). So it sounds to me like you were able to successfully verify the fix is working.

Flags: needinfo?(drno)

Comment 10

2 months ago

Verified as fixed on Firefox Nightly 67.0a1 (2019-02-04) on Windows 10 x 64, Windows 7 x32, Mac OS X 10.14 and on Ubuntu 16.04 x64.

Status: RESOLVED → VERIFIED
status-firefox67: fixed → verified
Blocks: 1376873
status-firefox65: affected → wontfix
No longer depends on: 1376873
Flags: in-testsuite+
(Assignee)

Comment 11

a month ago

Comment on attachment 9040321 [details]
Bug 1524145: set Opus stereo on send stream with 2 channels. r?dminor

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1376873

User impact if declined

Stereo sound in WebRTC no longer works.

Is this code covered by automated tests?

Yes

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

No

If yes, steps to reproduce

List of other uplifts needed

N/A

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

The patch only turns on certain features like stereo sound (and others) when using the Opus sound in WebRTC audio connections. This only happens when explicitly requested by the app (stereo is off by default), so it doesn't affect all WebRTC services.
Plus the code change is now covered with lots of additional testing.

String changes made/needed

N/A

Attachment #9040321 - Flags: approval-mozilla-beta?

Comment on attachment 9040321 [details]
Bug 1524145: set Opus stereo on send stream with 2 channels. r?dminor

Fix for recent regression, verified in nightly.
Code coverage looks good. Thanks for adding new tests!

Attachment #9040321 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Whiteboard: [qa-triaged]

Comment 13

a month ago
bugherderuplift
status-firefox66: affected → fixed

Comment 14

a month ago

Verified as fixed on Firefox 66.0b8 on Windows 10 x 64, Windows 7 x32, Mac OS X 10.14 and on Ubuntu 16.04 x64.

status-firefox66: fixed → verified
Flags: qe-verify+
QA Whiteboard: [qa-triaged]
Whiteboard: [qa-triaged]
You need to log in before you can comment on or make changes to this bug.