I've noticed a regression between a few months ago (which is the last time I used appear.in) and a few weeks ago with performance in appear.in calls. There's a very noticeable drift, with the sound going out of sync after a while. I end up reloading the page very often. Disabling the full_duplex configuration on the machine on the other end (a not-so-powered Windows machine; my machine is instead a Lenovo W541 with Linux) improved things. The performance on https://appr.tc/, instead, is much better.

Thanks for reporting! What version of Firefox are you running? We've been looking for this drift problem. Would you mind running http://mozilla.github.io/mozregression/ to find a regression range?

I'm running Nightly on Linux, the other end is running Beta on Windows. Not sure I will be able to run mozregression, as the other end would need to be involved as well.

Oh the problem only happens with calls to this other peer? It doesn't manifest if e.g. you join the same appear.in room from two tabs in the same browser?

(In reply to Jan-Ivar Bruaroey [:jib] from comment #3) > Oh the problem only happens with calls to this other peer? I'm not sure. > It doesn't manifest if e.g. you join the same appear.in room from two tabs in the same > browser? Is there a way to do that? If I try, only one of the tabs is able to get access to camera and microphone (or only one of the browsers, if I try to open appear.in in a separate Firefox instance).

I experience this very same problem, but also with other webrtc sites like meet.jit.si

Nukeador, what's your exact setup? Machine, OS version headset brand and model, etc. ?

(In reply to Paul Adenot (:padenot) from comment #6) > Nukeador, what's your exact setup? Machine, OS version headset brand and > model, etc. ? Firefox Nightly, Carbon X1 laptop, Ubuntu 16.04 LTS, Plantronics Headset (but also happen with any other audio output device)

(In reply to Rubén Martín [:Nukeador] from comment #7) > (In reply to Paul Adenot (:padenot) from comment #6) > > Nukeador, what's your exact setup? Machine, OS version headset brand and > > model, etc. ? > > Firefox Nightly, Carbon X1 laptop, Ubuntu 16.04 LTS, Plantronics Headset > (but also happen with any other audio output device) And the other side of this two way call ?

(In reply to Paul Adenot (:padenot) from comment #8) > And the other side of this two way call ? This happens with anyone on the other side. Windows, Linux, Macs...

Alex, any idea here ?

Not out of my head, we do not have issues with linux backend. Can you please go in about::config and create an new pref with name "media.cubeb.backend" (string) and set it to "pulse" (restart required)? After check if the drift issue is still there.

We were having a call using Appear.in using a Windows and a Mac computer, both using Nightly. We both sounded like robots and the image froze often as well. It was like two Daleks having a 1:1. At some point we gave up and moved to Chrome (using the same computers) and the issues went away.

Just had a chat with sole on irc. She's using an Apple Macbook (non-pro) and the other person was using an XPS15 running Windows 10.

Last time I checked I got the same behaviour Sole and Paul described here.

We've found a recent regression, that was the cause of sole's bug. We're just kickstarting an effort to improve call quality on all platforms (especially when there is a lower-end device on one side), although we haven't really opened bugs about it.

Mass change P1->P2 to align with new Mozilla triage process

Why the title change? I could reproduce this bug without any headset. Bug 1393689 seems to be about a slow drift, in my case the audio was going out of sync quite quickly.

After in depths analysis, we found that it's the same underlying problem. Sorry for the confusion, we're trying to consolidate the different bugs to facilitate tracking and not let anything slip through.

(In reply to Paul Adenot (:padenot) from comment #19) > After in depths analysis, we found that it's the same underlying problem. > Sorry for the confusion, we're trying to consolidate the different bugs to > facilitate tracking and not let anything slip through. It's great to hear you've found the root cause!

Yes. To be explicit, the root cause was that we're spending to much time rendering the output audio, which under-runs, and this let the input audio buffer. Expect a fix in nightly, that I'll try to uplift, soon.

(In reply to Marco Castelluccio [:marco] from comment #18) > Why the title change? I could reproduce this bug without any headset. Sorry, I based that on comment 7. Removed in title again.