recording audio from mic slowly starts to lag real time

RESOLVED DUPLICATE of bug 1243857

Status

()

P2
normal
Rank:
23
RESOLVED DUPLICATE of bug 1243857
2 years ago
2 years ago

People

(Reporter: dlm, Unassigned)

Tracking

47 Branch
x86_64
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8770805 [details]
index.html

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

Steps to reproduce:

Using getUserMedia createMediaStreamSource and createScriptProcessor to collect audio from the mic.


Actual results:

The onaudioprocess slowly lags behind. After about 15 minutes the mic input is 1 sec behind user speech, this continues, ive tried it after 2 hours and is was about 8 seconds late.


Expected results:

Edge and Chrome keep up, its not using cpu or memory, so must be a bug (or i did something wrong in my attached example) I've attached a simple example with a peek meter. Just open page, say something, wait 30 min then say something again, you will see the delay.
(Reporter)

Updated

2 years ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
(Reporter)

Comment 1

2 years ago
tried it on OS X 10.11.5 no issues

Updated

2 years ago
Component: Untriaged → Web Audio
Product: Firefox → Core
I presume this is a small sampling rate mismatch/drift issue; which would be hardware (and hardware setting) dependent.
Status: UNCONFIRMED → NEW
Rank: 23
Ever confirmed: true
Flags: needinfo?(padenot)
Priority: -- → P2
(Reporter)

Comment 3

2 years ago
If it were hardware alone, you'd see it on Chrome and Edge, but you don't. Is Firefox doing some odd HW configuration, if so that could be the issue otherwise its SW. I've start all three browser (latest version on Windows 10, NOTE chrome need a server i use python -m SimpleHTTPServer the file must be index.html in the same dir) then just wait, you see the differences.
(Reporter)

Comment 4

2 years ago
Of course it could be the other browsers are noticing the drift and dealing with it.
Hi,

Could you give me your exact setup, as in, are you using a latop, desktop, a specific sound card or headset, or a combination of sound cards and headsets, etc. ?

What you said in comment 4 is probably what's happening.
Flags: needinfo?(padenot) → needinfo?(dlm)
(Reporter)

Comment 6

2 years ago
Of the 3 computers i tried it on, only my desktop has the issue:
Dell XPS 8700 i7-4770 @3.4 GHz, 16 GB RAM, 64 bit Windows 10
Built in sound chip REALTEK ALC3861 Realtek High Definition Audio
Mic is Microsoft LifeCam VX-5000 

Turns out its the LifeCam VX-5000, 
plugging in a generic headset into the audio port works just fine.
It has a USB connection (USB 2.0)!
I'll try some other USB audio devices I have and let you know and 
i'll try the LifeCam on my laptop was well.
Please also go into the Sound settings and find out what sampling rates the mic is using (44100, 48000, 32000, etc).

Also please try it with Nightly (nightly.mozilla.org); that uses "full-duplex" audio which may help compensate for input/output drifts.  (It's in more than Nightly, depending on OS, but let's start there.)  You can verify if that's the cause (assuming Nightly doesn't drift with the VX-5000) by using about:config and searching for full_duplex, and changing the setting.  (To be safe I'd advise restarting the browser after changing the value; it might not always be needed, but that way you're sure.)
(Reporter)

Comment 8

2 years ago
Toggling full_duplex in Nightly makes the problem come and go, so full_duplex helps. I only tried to for 30 min but that would have given a very noticeable delay. I'll try something longer when I get a chance.
I also tried a Sennheiser USB Headset, it did not have the problem (they both use the same Microsoft USB driver) I tried the VX-5000 at 48000 Hz (the default) and 44100 Hz, both had the problem, but 44Khz seemed a bit less (but its hard to judge) 
I also tried plugging the VX-5000 into a USB 3 slot, but no help.
I have another USB mic i will try, do you want me to try anything else?
So this is solved by full_duplex, as expected.  Due to how clock drift between different computers is handled in WebRTC (PeerConnections), this doesn't affect calls, but does affect local use of streams if the mic and the output channel run off different clock sources (and thus drift).  It's a rather silly HW design for a USB headset, but not too surprising for a pure USB mic (or USB camera+mic) (though the driver could have compensated for this).

full_duplex is on for windows in Aurora/49, which goes to release in around 8ish weeks.  It's on in Linux in Beta/48 (release in a few weeks), and on Mac will be on in 50/Nightly in a day or so, and that may or may not get uplifted to 49.

Thanks for doing the checking!
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1243857
(Reporter)

Comment 10

2 years ago
So good news, tested out well over an hour and no noticeable drift, but at 44.1KHz.
Bad news, when i switched to 48Khz it slips 1 second in just 10 seconds, continuously...
(In reply to dlm@vitruvi.co from comment #10)
> So good news, tested out well over an hour and no noticeable drift, but at
> 44.1KHz.
> Bad news, when i switched to 48Khz it slips 1 second in just 10 seconds,
> continuously...

Full Duplex or not?  Which firefox version?
Padenot, do you or anyone else in your office have a VX-5000?
https://www.amazon.com/Microsoft-RKA-00001-LifeCam-VX-5000-Blue/dp/B0015BWO5W/ref=sr_1_2?ie=UTF8
Flags: needinfo?(padenot)
No but I can buy one, it's cheap.
Flags: needinfo?(padenot)
(In reply to dlm@vitruvi.co from comment #10)
> So good news, tested out well over an hour and no noticeable drift, but at
> 44.1KHz.
> Bad news, when i switched to 48Khz it slips 1 second in just 10 seconds,
> continuously...

Is this with nightly or release ? With or without the full-duplex pref ?
(Reporter)

Comment 14

2 years ago
This is with nightly and full duplex on.
I ordered the same camera and will diagnose when it's here.

Thanks for all the info, we'll get that fixed hopefully soon.
Flags: needinfo?(dlm)
You need to log in before you can comment on or make changes to this bug.