Closed Bug 1247574 Opened 5 years ago Closed 4 years ago

High pitch audio during WebRTC call using Jabra headsets and Logitech C920 webcams

Categories

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

44 Branch
Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox46 --- fixed
firefox47 --- fixed
firefox48 --- fixed
firefox-esr45 --- fixed
Blocking Flags:

People

(Reporter: matthias.schertler, Assigned: jesup, NeedInfo)

References

Details

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160208194709

Steps to reproduce:

Firefox 44 or Firefox 45.0b (Firefox 43 works fine)
Jabra BIZ 2400 USB headset
Windows 10

I do an outgoing WebRTC call. The call is connected and there is audio in both directions.


Actual results:

The remote party hears my voice in a very high pitch (Mickey Mouse voice). I think the audio is captured or encoded in a wrong sampling rate.

I can reproduce this on different PCs with different Jabra Headsets. It is independent of the remote party (Firefox, Chrome, VoIP phone).

With the built in microphone of my notebook there is no problem. Also with a Plantronics headset it works fine.

It seems to be independent of the used codec. Same problem with PCMA/8000 and with G722/8000/1.


Expected results:

Normal audio.
OS: Unspecified → Windows 10
Component: Untriaged → WebRTC
Product: Firefox → Core
Component: WebRTC → WebRTC: Audio/Video
Matthias: Can you run with these env variables set (see https://wiki.mozilla.org/Media/WebRTC/Logging):
NSPR_LOG_MODULES=mediamanager:4,getusermedia:4,webrtc_trace:65535 WEBRTC_TRACE_FILE=nspr NSPR_LOG_FILE=some_file

It can be a very short call or capture via https://mozilla.github.io/webrtc-landing/gum_test.html (select Audio probably)

Also: what exact version of Jabra?  What type of connection? (analog, USB, bluetooth)?  What OS?  What drivers?  What Firefox versions tested?

Thanks!
Flags: needinfo?(matthias.schertler)
Attached file webrtc.txt
Hello Randell,

I added the requested trace file (webrtc.txt). The trace looks to me like there is some sampling rate issue. The device captures at 32000 but the recording sampling rate is 16000.

> what exact version of Jabra?
Jabra BIZ 2400

> What type of connection?
USB

> What OS?
Windows 10

> What drivers?
Jabra BIZ 2400 USB, Version 10.0.10240.16384, 2015-07-09

> What Firefox versions tested?
Firefox 44 - working
Firefox 44 - not working
Firefox 45.0b - not working
Firefox 45.0b6 - not working

Regards, Matthias
Flags: needinfo?(matthias.schertler)
(In reply to Matthias Schertler from comment #2)
> Created attachment 8720365 [details]
> webrtc.txt

> I added the requested trace file (webrtc.txt). The trace looks to me like
> there is some sampling rate issue. The device captures at 32000 but the
> recording sampling rate is 16000.

Thanks for the log!


> > What Firefox versions tested?
> Firefox 44 - working
> Firefox 44 - not working
> Firefox 45.0b - not working
> Firefox 45.0b6 - not working

Ummm... perhaps that first one was 43?  Or was it a different version of 44, or different machine?
Also: 45.0b - that should have a number after 'b'

I believe in 44 we switched getUserMedia capture from 16000 to 32000Hz, which also means we ran the AEC at a higher frequency range.

Thanks!
Flags: needinfo?(matthias.schertler)
You are right, that was a typo.

Firefox 43 was working
Firefox 44 and 45 is not working
Flags: needinfo?(matthias.schertler)
Duplicate of this bug: 1252040
P1 to figure out what's happening (and the report in the dup that it applies to C920s).  Very likely this is related to the switch to 32Khz sampling in 44.
Status: UNCONFIRMED → NEW
backlog: --- → webrtc/webaudio+
Rank: 19
Ever confirmed: true
Priority: -- → P1
Summary: High pitch audio during WebRTC call using Jabra headsets → High pitch audio during WebRTC call using Jabra headsets and Logitech C920 webcams
Can you try to capture a sample of the AEC data by starting a call to someone, and then browsing to about:webrtc and selection Start AEC Debug Log, let it run for maybe 30 seconds, then Stop the logging and upload all the files it creates?  (put them in a tgz or zip)

That would let me hear the audio directly. I doubt the AEC per se is involved.

The 16KHz sample rate is interesting, and likely related to the problem, though upsampling 16->32KHz should work fine.

Thanks!
Assignee: nobody → rjesup
Flags: needinfo?(matthias.schertler)
Two different sets of AEC logging from my Win7 laptop when using the Logitech C920 microphone.
Sound is perfectly normal when I chose the internal microphone of the laptop. Interesting is also that Firefox shows me two Logitech C920 microphones, although the Windows hardware manager only shows one. But it does not matter which of the two mics I chose, they both result in a Mickey Mouse sound.
The AEC logs were taken with today public build of Firefox 48.
Attached file matthias-aec.zip
Sorry for the delay.

Please see the attached AES logs (matthias-aes.zip). Captured with Firefox 45.0 and the Jabra Headset.
Flags: needinfo?(matthias.schertler)
Duplicate of this bug: 1256971
We tap audio off in external-processing callbacks, which is before the final EncodeAndSend() upsample to the target rate.  This solves the problem by forcing resampling to the target rate even if that's an upsample.  Alternatively we could resample in Process() before AppendToTrack, or (best of all, if we care a lot) read the HW frequency after StartSend and before registering the callback and before AddTrack, and use that rate (with the same std::min()) as the track rate.  While this will have slightly lower quality and higher CPU use than the 'best' solution, it's only slight, and in a case we don't care a ton about.
Attachment #8732548 - Flags: review?(padenot)
Sorry, use https://treeherder.mozilla.org/#/jobs?repo=try&revision=7875d1300d03 to test - forgot to pop an unrelated patch off the last Try
Could you try one of the Try builds to see if this resolves the problems for you:

Win8x64 opt: 
http://archive.mozilla.org/pub/firefox/try-builds/rjesup@wgate.com-7875d1300d039650814191ceabf9b574633e4c59/try-win64/firefox-48.0a1.en-US.win64.installer.exe

or the win32 ("WinXP") opt build (not complete yet: go to https://treeherder.mozilla.org/#/jobs?repo=try&revision=7875d1300d03 and click on the B for WinXP opt, then click on the link for Build: in the lower left, then download and install the installer.)

Thanks!
Flags: needinfo?(roland.buerkel)
Flags: needinfo?(matthias.schertler)
Flags: needinfo?(kamal.bhatt)
(In reply to Randell Jesup [:jesup] from comment #15)
> Could you try one of the Try builds to see if this resolves the problems for
> you:
> 

I tested this Win8x64 build and I can confirm that it resolves the problem here.
I have Jabra Speak 410 device on Win 8.1x64 and I used https://meet.jit.si/YourOwnRandomId WebRTC service to test. With this Jitsi service we have seen the same audio problem on FF 44-45 with Jabra devices.
- FF 45.0.1 opens meet.jit.si link, another pc Chrome 49.0.2626 user opens the same link: Chrome user hears mickeymouse audio from FF
- FF 48.0.a1 opens meet.jit.si link, another pc Chrome 49.0.2626 user opens the same link: Audio is normal both directions
Duplicate of this bug: 1257507
Cool, can we get this landed today/tonight and then ask for uplift?
Rank: 19 → 10
Flags: needinfo?(rjesup)
I can also confirm that the Build from comment 15 solves the problem. :)
Flags: needinfo?(matthias.schertler)
Attachment #8732548 - Flags: review?(padenot) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/88a8fe526ba3f7bc7aec06bac5b0e88b968baec1
Bug 1247574: Force webrtc audio input processing to resample to target rate to fix 16KHz mics. r=padenot
Comment on attachment 8732548 [details] [diff] [review]
Force webrtc audio input processing to resample to target rate to fix 16KHz mics

Approval Request Comment
[Feature/regressing bug #]: bug 953265
[User impact if declined]: Unusable audio with a particular headset, because of bad interaction between external code (webrtc.org) and the audio driver.
[Describe test coverage new/current, TreeHerder]: this is not testable on automation, it requires a very particular headset. We have plans to make this testable, but it's very involved.
[Risks and why]: Tested by Nils and the reporter of the bug.
[String/UUID change made/needed]: none
Flags: needinfo?(rjesup)
Attachment #8732548 - Flags: approval-mozilla-esr45?
Attachment #8732548 - Flags: approval-mozilla-beta?
Attachment #8732548 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/88a8fe526ba3
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Comment on attachment 8732548 [details] [diff] [review]
Force webrtc audio input processing to resample to target rate to fix 16KHz mics

Fix for bad audio on particular hardware + WebRTC. 
This should land in beta 5.
Attachment #8732548 - Flags: approval-mozilla-beta?
Attachment #8732548 - Flags: approval-mozilla-beta+
Attachment #8732548 - Flags: approval-mozilla-aurora?
Attachment #8732548 - Flags: approval-mozilla-aurora+
Comment on attachment 8732548 [details] [diff] [review]
Force webrtc audio input processing to resample to target rate to fix 16KHz mics

OK, polish esr45, taking it.
Should be in 45.1.0
Attachment #8732548 - Flags: approval-mozilla-esr45? → approval-mozilla-esr45+
You need to log in before you can comment on or make changes to this bug.