Closed Bug 1269019 Opened 8 years ago Closed 4 years ago

opus fmtp stereo=1 does not cause Firefox to send stereo

Categories

(Core :: WebRTC: Audio/Video, defect, P4)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: bwc, Unassigned)

Details

See https://bugzilla.mozilla.org/show_bug.cgi?id=818618#c47

It is possible there has been a regression since bug 818618 landed, or perhaps something in the codec configuration code is causing a fallback to some other (mono, low-quality) codec.
Even if stereo is negotiated, you still won't get a stereo signal (at the other end) unless everything between a (stereo) mic and the webrtc code is stereo.  Right now, I believe the AEC is mono-only.  (Stereo AEC use is very tricky.)

Bug 818618 did not (and was not meant to) guarantee we'd send a real stereo signal.  It means we will receive stereo, and we may send a "stereo" signal - but if the input is mono, then you'll get a signal with the same data in each channel.  For stereo capture, see bug 971528

To test this bug, you need a stereo audio source such as video.captureStreamUntilEnded or a WebAudio source.  Just setting up a call with gUM won't tell you anything.  A webaudio source with audio bouncing from one side to the other, or simply different audio in each channel should do.

This would become more important if we have stereo gUM.  There are some usecases with stereo WebAudio of captureStream'd audio, but they're small, relatively.
Rank: 35
Priority: -- → P3
Well, I can only say that in my case, the whole signal line *is* in fact stereo. I'm using an input signal from a virtual audio device (Soundflower on Mac OS) which is hooked to Ableton Live.

If I send this signal from Chrome to Firefox, I can hear it in perfect hi-fi quality. But if I try it the other way around (Firefox sends to Chrome), I only hear bad mono quality. And it also sounds as if AEC is active in this case, although I disabled it using this constraint:

audio: {
        mandatory: {
          echoCancellation: false,
          googEchoCancellation: false,
        },
        optional: [{
          sourceId: <deviceId of the Soundflower device>
        }]
      }

Does your statement mean that this won't disable AEC and still deliver a mono signal on Firefox? If so, how exactly could I hook an external audio device to a web audio source, if not using gUM?
The mandatory / optional syntax was deprecated years ago.  Chrome is (last I checked) using the ancient constraint syntax still.  That won't work in Firefox.

use audio: { echoCancellation: false }

Note: adapter.js will let you use spec-compliant constraints with Chrome or Firefox.
Sorry, I forgot to mention that I *am* using adapter.js, so my syntax is automatically translated to Firefox. :-)
You can verify if it's being handled correctly by adapter.js (I haven't tried echoCancellation with it myself) by going into about:config and turning off all AEC with media.getusermedia.aec_enabled = false
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4

afaik this works well and has worked for years.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.