1610647 - Distorted and accelerated voice recorded

Status: VERIFIED FIXED

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

Description

[s4per89]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

Recording voice sample on https://voice.mozilla.org/pl/speak

Actual results:

Recorded voice have distortions and was accelerated. (tested on 73.0b7 and Nightly for 2020-01-21; works fine on stable release )

Expected results:

clear voice in normal speed

Comment 1

[Augusto Pace]

Hi,

I was NOT able to reproduce this issue on Windows 10 with Firefox version Nightly 74.0a1 (2020-01-27) (64-bit) - Beta 73.0b10 (64-bit).

@[e-mail] Could you please try on our latest Nightly build (you can download it here: https://nightly.mozilla.org/). Also please try with a NEW PROFILE and SAFE MODE browser in case any external component is affecting.
I'm setting component to Core - WebRTC: Audio/Video.

Comment 2

[s4per89]

(In reply to Augusto Pace from comment #1)

Hi,

I was NOT able to reproduce this issue on Windows 10 with Firefox version Nightly 74.0a1 (2020-01-27) (64-bit) - Beta 73.0b10 (64-bit).

@[e-mail] Could you please try on our latest Nightly build (you can download it here: https://nightly.mozilla.org/). Also please try with a NEW PROFILE and SAFE MODE browser in case any external component is affecting.
I'm setting component to Core - WebRTC: Audio/Video.

Hi,

Now works absolutely fine on 74.0a1 (2020-01-28) (64 bity). I tried once again on 73.0b10 (64 bity) to be sure, that it's not related to update of OS, and it looks like on 73.0b10 (64 bity) problem is still existing.

Comment 3

[Matthew Gregan [:kinetik]]

@s4per89 Thanks for the update, glad to hear it appears to be resolved in current Nightly versions. Is it correct to assume that you didn't experience this issue in 72?

It'd be helpful to understand if this is a regression in beta that has since been fixed in nightly or if there's some other reason for the issue appearing and disappearing. If you're able to reproduce the issue consistently, it'd be very much appreciated if you ran mozregression (https://mozilla.github.io/mozregression/quickstart.html) to help us narrow down the change that introduced the issue.

Comment 4

[s4per89]

That's right - works fine on 72.

Mozgression log:

2020-01-29T21:55:09: DEBUG : Found commit message:
Bug 1603384 - Update cubeb from upstream to aa63601. r=padenot

Differential Revision: https://phabricator.services.mozilla.com/D56872

2020-01-29T21:55:09: DEBUG : Did not find a branch, checking all integration branches
2020-01-29T21:55:09: INFO : The bisection is done.
2020-01-29T21:55:09: INFO : Stopped

I hope that it will be helpful. If not please let me know how can I help with it.

Comment 5

[Matthew Gregan [:kinetik]]

Thanks, that's very helpful! Can you please also attach the Media section from about:support? That may help with resolving bug 1590902, since that's likely to be related to particular audio devices.

Looking at the actual changes (rather than the change list generated by update.sh) that landed in bug 1603384, I see IAudioClient3 has been accidentally re-enabled (disabled in bug 1590652 due to similar problems), so that's almost certainly the cause of this issue. It looks like media/libcubeb/disable-iaudioclient3.patch didn't apply during the import. We'll need to uplift disabling IAudioClient3 to beta again.

Nightly is unaffected due to a later libcubeb update in bug 1610527 applying disable-iaudioclient3.patch as expected.

We'll also disable it in upstream libcubeb for now, since there's not much point leaving it enabled there until we have time to investigate bug 1590902.

Comment 6

[Matthew Gregan [:kinetik]]

Attachment: Bug 1610647 - Revert unintentionally re-enabled IAudioClient3. r?achronop

Comment 7

[Matthew Gregan [:kinetik]]

Comment on attachment 9123565 [details]
Bug 1610647 - Revert unintentionally re-enabled IAudioClient3. r?achronop

Beta/Release Uplift Approval Request

• User impact if declined: Audio glitches of various sorts on Windows 10
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Re-applying the revert we already did in bug 1590652, so this is totally safe.
• String changes made/needed:

Comment 8

[s4per89]

Attachment: Media Mechanizm dźwięku wasapi Maksymalna liczba kanałów 2 Preferowana częstotliwość próbkowania 48000 Urządzenia wyjściowe Nazwa Grupa Dostawca Stan Preferowane Format Kanały Częstotliwość próbkowania Opóźnienie Digital Audio (HD

(In reply to Matthew Gregan [:kinetik] from comment #5)
> Thanks, that's very helpful!  Can you please also attach the Media section from about:support? That may help with resolving bug 1590902, since that's likely to be related to particular audio devices.
> 
> Looking at the actual changes (rather than the change list generated by update.sh) that landed in bug 1603384, I see IAudioClient3 has been accidentally re-enabled (disabled in bug 1590652 due to similar problems), so that's almost certainly the cause of this issue.  It looks like media/libcubeb/disable-iaudioclient3.patch didn't apply during the import.  We'll need to uplift disabling IAudioClient3 to beta again.
> 
> Nightly is unaffected due to a later libcubeb update in bug 1610527 applying disable-iaudioclient3.patch as expected.
> 
> We'll also disable it in upstream libcubeb for now, since there's not much point leaving it enabled there until we have time to investigate bug 1590902.

about:support

Comment 9

[Matthew Gregan [:kinetik]]

(In reply to s4per89 from comment #8)

about:support

Thank you. I've made a note in bug 1590902 about the audio hardware in use for when we have time to investigate the root cause of this issue.

Comment 10

[Matthew Gregan [:kinetik]]

(In reply to Matthew Gregan [:kinetik] from comment #5)

We'll also disable it in upstream libcubeb for now, since there's not much point leaving it enabled there until we have time to investigate bug 1590902.

This was done in https://github.com/kinetiknz/cubeb/commit/2b79f196c0fc61e125463b74c2da96b77d76eb6f

Comment 11

[Julien Cristau [:jcristau]]

Comment on attachment 9123565 [details]
Bug 1610647 - Revert unintentionally re-enabled IAudioClient3. r?achronop

approved for 73.0b12

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f01dc6936ff4

Comment 14

[Daniel Bodea [:danibodea]]

I have verified this fix in Beta Candidate v73.0b12.
Tested with both https://mozilla.github.io/webrtc-landing/gum_test.html and https://voice.mozilla.org/pl/speak .

Thank you.