Closed Bug 1584560 Opened 6 months ago Closed 6 months ago

Wrong input channel count on gUM without settings

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox71 --- verified

People

(Reporter: achronop, Assigned: achronop)

Details

Attachments

(1 file)

When a gUM({audio: true}) is executed, the number of channels of the input device, in the AudioCallbackDriver, is 1 instead of 2 (which is the expected for my device).

The problem lies in the calculation of channel count in MediaEngineWebRTCMicrophoneSource::EvaluateSettings [1]. The logic there tests whether channel count has been provided, in line 118 aInPrefs.mChannels <= 0, and updates the prefs.mChannels accordingly. But in lines 124, 125 aInPrefs.mChannels, which is always 0 with default settings, is used, instead of the updated prefs.mChannels. That results in input channel count = 1 every time the default settings are being used.

[1] https://searchfox.org/mozilla-central/rev/f1e99da78fe6c3c68696358dac06aed90f8112d3/dom/media/webrtc/MediaEngineWebRTCAudio.cpp#118-126

In MediaEngineWebRTCMicrophoneSource::EvaluateSettings, on default settings, the prefs.mChannels is updated accordingly. However, it is not used for the calculation of the FlattenedConstraints. As a result, the channel count is 0, which is converted to 1, and not the actual device channel count as it should. Thus, the prefs.mChannels is used in the calculation of the FlattenedConstraints.

Pushed by achronopoulos@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c6d0570a09ee
On default settings use the actual device channel count. r=padenot
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Is there anything here that could be covered by the manual QA ? Thank you!

Flags: needinfo?(achronop)

You can verify this issue by using the test page in [1] and a stereo microphone (which I guess is what you have by default). Use the button labeled "default" to run the test. Before the fix, input audio was mono, which means that it was containing one channel, and only one of the two graphs was active. After the fix, the audio input is stereo and both graphs are active.

[1] https://jsfiddle.net/achronop/2jgob190/

Flags: needinfo?(achronop)

(In reply to Alex Chronopoulos [:achronop] from comment #6)

You can verify this issue by using the test page in [1] and a stereo microphone (which I guess is what you have by default). Use the button labeled "default" to run the test. Before the fix, input audio was mono, which means that it was containing one channel, and only one of the two graphs was active. After the fix, the audio input is stereo and both graphs are active.

[1] https://jsfiddle.net/achronop/2jgob190/

Thank you for your help! I will therefore set this to qe+ as part of 71 beta bug verification!

Flags: qe-verify+

Confirmed issue with 71.0a1(2019-09-27).
Fix verified with 71.0b8 on Windows 10, macOS 10.13.6, Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.