New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 905083 link

Starred by 21 users

Issue metadata

Status: Verified
Owner:
Closed: Nov 16
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Blocked on:
issue 895338



Sign in to add a comment

Choppy/robotic audio with some headsets with Chrome on Windows 10

Reported by avasi...@twilio.com, Nov 14

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Example URL:
https://hangouts.google.com/

Steps to reproduce the problem:
Since 10/24/2018 we have seen a drastic uptick in reports of degraded audio (choppy, robotic, helicopter sound) in webrtc calls from Chrome 70.0.3538.77 on Windows 10 (version:1803 build:17134.345)
Most commonly the issue is reported with following headsets: Jabra 9450, Jabra Pro 9460 Series, Logitech Dual H820e 

Note: the issue does not happen in Firefox on the same windows machine. Also not reproducible with the same Chrome version and headset on Mac. 

Steps:
1. Connect headphones to your machine and set it as a default audio input/output. 
2. Open Google hangouts 
2. Start a Voice call to a phone number

Result: Audio from Google hangouts is distorted for a phone call recipient. Audio file attached. 

What is the expected behavior?
Good audio quality

What went wrong?
Audio is distorted (robotic choppy audio) from call participant on Chrome/Windows Audio file attached. 

Did this work before? Yes 

Is it a problem with Flash or HTML5? N/A

Does this work in other browsers? Yes

Chrome version: 70.0.3538.77  Channel: stable
OS Version: version:1803  Build:17134.345
Flash Version: 

Contents of chrome://gpu:
 
Components: -Internals>Media Blink>WebRTC>Audio

Comment 2 Deleted

Initially the issue was reported by Twilio customers with Twilio webrtc based product, but after troubleshooting it was reproduced with other products like Google Hangouts. The issue seems to be somewhat related to that specific version of Windows and Chrome as it does not happen with Firefox on that same machine. 
Let us know what information can help to diagnose. 
I am attaching the distorted audio example and webrtc internals file for the affected call.
Recording - NVM Platform.wav
506 KB Download
Internals.txt
3.9 MB View Download
Labels: Needs-Bisect Needs-Triage-M70
Cc: swarnasree.mukkala@chromium.org
Components: Platform>Apps>Hangouts
Labels: Triaged-ET
Tried testing the issue on reported chrome version #70.0.3538.77 by following steps as per comment#0, unable to place the call as it is chargeable. Requesting someone from respective team to look into the issue, tentative adding Platform>Apps>Hangouts.

Attached screenshot for reference.
Thanks.!
hangouts_(voice call).PNG
294 KB View Download
Cc: solenberg@google.com
Labels: Needs-Feedback
Owner: hlundin@chromium.org
Thanks for reporting. This does not sound very good at all.

To get a better handle of the problem, we would need some more recordings and information from the Chrome side.

1. Open up chrome://webrtc-internals (preferably before setting up the call, but it is ok to do it mid-call too). 
2. Expand the "Create Dump" section.
3. Check "Enable diagnostic audio recordings"; select a path and filename (default is fine).
4. Check "Enable diagnostic packet and event recording"; select path and filename (again, default is fine).
5. Make sure that the problem is reproduced while the recordings are running.

After the call, uncheck these boxes, and share the files in this bug, or with me directly (Google Drive, Dropbox, etc). You will get a number of files. There is information in chrome://webrtc-internals/ about the file names, but it is probably easiest to find them by date and time. Try to keep the recording to maximum a few minutes, or the files will be very large.

PRIVACY NOTE: The recordings will contain the audio for both directions of the call; what you or the other end say will be heard in the recording.

Finally, open up chrome://version and copy all the hashes under Variations. Just paste them here.

Thanks!
Audio and event output from a Hangouts repro on 11/12 is attached. 

Version Variations:	
411b6d4e-ca7d8d80
b7d3b6c2-3f4a17df
d01ab0d3-ca7d8d80
3e006338-3f4a17df
1a0d11d4-2f9febdf
2b6ab552-ca7d8d80
66df3e9d-7f918788
ebeb14fc-3f4a17df
b7e2524c-1181467f
cc20827f-ca7d8d80
3095aa95-3f4a17df
c27fec31-2d5b6ed9
7c1bc906-f55a7974
9def365c-ca7d8d80
47e5d3db-3d47f4f4
125b7f68-898170a5
d442dfb7-ca7d8d80
9ca1387e-3f4a17df
1149accc-5c943877
4dc30737-b8a5ea08
a582a1b8-ad75ce17
e56c5101-7d60f345
aa011017-3f4a17df
88a387d2-ee748cef
334aa58d-3f4a17df
edbcf7c5-1cc1312c
9b4c4257-ca7d8d80
43f62d3b-28165b59
3a0563a1-13b68faf
6a82868d-3f4a17df
9e5c75f1-a589001b
6872f671-991e1e1
2b86fd96-3f4a17df
d1cd70a5-ca7d8d80
4ea303a6-ecbb250e
6e6e0c7e-3f17a7d8
d92562a9-4d2fac87
fc369826-ca7d8d80
7aa46da5-c946b150
4da5ae82-91c810ef
2c1d398c-3f4a17df
cc54eb06-20131bcc
58a025e3-36e97b2c
df072bba-ca7d8d80
5586049f-3f4a17df
4bc337ce-7b60a216
1354da85-f1a864dc
494d8760-52325d43
f47ae82a-746c2ad4
3ac60855-486e2a9c
f296190c-6754d7b7
4442aae2-a90023b1
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-75cb33fc
e7e71889-4ad60575
b1ceb06f-d1372334
94e68624-803f8fc4
cc73f8a1-ca7d8d80
10a311eb-ca7d8d80
8834fcca-28975df1
6204e469-ca7d8d80
81c6897f-35fec36d
ea0f933d-29e3c6de

hangoutsReproDump.zip
8.0 MB Download
Thanks @Hlundin.  I am onsite and able to replicate. So any additional details needed please let me know. Attaching the exports with some additional information here.

Within the zip is the following:
1-Test_Scenario_Details.txt - Basic run down of my test
2-Audio_Recv_from_Cilent.wave - RTP Capture on far end from client
3-Version_Details.txt - Chrome Version export requested
4-Jabra860_Device_Drivers.PNG - The device being used and generic driver associated from Win10
5-JitterBuffer_Flucuation_by_Headset_on_Single_Call.PNG - A test call I did the other day by hotswaping headsets mid call and monitoring the WebRTC Internals Jitter Buffer. There was no correlation with actual Jitter occuring.
Other files-As is exported by WebRTC Internals dump

Here is the version output:

Google Chrome	70.0.3538.102 (Official Build) (64-bit) (cohort: Stable)
Revision	4bbeebac88fdc09c97265e47c205868bbd190497-refs/branch-heads/3538@{#1077}
OS	Windows
JavaScript	V8 7.0.276.38
Flash	31.0.0.148 C:\Users\Al Brooks\AppData\Local\Google\Chrome\User Data\PepperFlash\31.0.0.148\pepflashplayer.dll
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end --restore-last-session --flag-switches-begin --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path	C:\Users\Al Brooks\AppData\Local\Google\Chrome\User Data\Default
Variations	411b6d4e-ca7d8d80
b7d3b6c2-3f4a17df
d01ab0d3-ca7d8d80
3e006338-3f4a17df
2b6ab552-ca7d8d80
66df3e9d-7f918788
b7e2524c-1181467f
cc20827f-ca7d8d80
8502ae4f-e1031ab5
3095aa95-3f4a17df
c27fec31-2d5b6ed9
7c1bc906-f55a7974
9def365c-ca7d8d80
47e5d3db-3d47f4f4
125b7f68-898170a5
d442dfb7-ca7d8d80
9ca1387e-3f4a17df
1149accc-5c943877
4dc30737-b8a5ea08
a582a1b8-ad75ce17
e56c5101-7d60f345
5c72c65a-ca7d8d80
267255c3-f4950e99
249dd49a-62714bf0
aa011017-3f4a17df
88a387d2-ee748cef
334aa58d-3f4a17df
edbcf7c5-1cc1312c
9b4c4257-ca7d8d80
43f62d3b-28165b59
3a0563a1-13b68faf
6a82868d-3f4a17df
9e5c75f1-1039a221
6872f671-991e1e1
2b86fd96-3f4a17df
d1cd70a5-ca7d8d80
4ea303a6-ecbb250e
6e6e0c7e-3f17a7d8
d92562a9-4d2fac87
fc369826-ca7d8d80
7aa46da5-c946b150
4da5ae82-91c810ef
2c1d398c-3f4a17df
cc54eb06-20131bcc
58a025e3-36e97b2c
df072bba-ca7d8d80
5586049f-3f4a17df
4bc337ce-55ac272c
1354da85-f1a864dc
494d8760-52325d43
f47ae82a-746c2ad4
3ac60855-486e2a9c
f296190c-6e3b1976
4442aae2-d7f6b13c
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-92bb99a9
e7e71889-e1cc0f14
b1ceb06f-d1372334
94e68624-803f8fc4
cc73f8a1-ca7d8d80
10a311eb-ca7d8d80
8834fcca-28975df1
6204e469-ca7d8d80
8866fe4f-ca7d8d80
81c6897f-35fec36d
e0a8874-e0a8874
ea0f933d-29e3c6de
016712bc-ea58-b068-ed6f-645438e15c96.zip
3.8 MB Download
Cc: abdulsyed@chromium.org gov...@chromium.org
Labels: M-71 M-70
The file in #3 sounds like there are buffering issues, but none of that is present in the #8 zip file (looking at input debug recording). Haven't looked at the AEC dump yet. Was system under heavy load?

+grunell@ in case this could be traced to the buffer size experiment somehow - could you advice on which beta/canary to try and see if that might fix the problem?
Cc: hlundin@chromium.org
Labels: -Pri-2 -Needs-Feedback Pri-1
Owner: peah@chromium.org
Status: Assigned (was: Unconfirmed)
I analyzed the AECdump file in comment 7. The distortion is not present in the unprocessed mic signal, but it is very much present in the processed mic signal. That is, it seems that this effect is introduced in the processing.

peah@ does this reproduce in offline tools with the AECdump in comment 7?
All tests conducted on my end are during low CPU/Memory usage, and Chrome Performance Monitor and Chrome Tracing was used in previous tests did not show abnormal load. Win10 Task manager idle is sub 10% CPU usage and sub 50% memory. Typically running less during tests. Let me know if you need something more specific.

I did complete some verbose logging by running chrome with the following start parameters:
"chrome.exe --enable-logging --vmodule=*/webrtc/*=2,*/libjingle/*=2,*=-2 --no-sandbox"


Clips from that log show some interesting bits like these:

Line 190: [6336:12096:1113/203204.031:INFO:webrtcvoiceengine.cc(1501)] Setting voice channel options: AudioOptions {audio_jitter_buffer_max_packets: 50, audio_jitter_buffer_fast_accelerate: false, }

[6336:3896:1113/203223.380:WARNING:media_stream_audio_processor.cc(756)] Large audio delay, capture delay: 0ms; render delay: 390ms

[6336:3896:1113/203223.730:WARNING:render_delay_buffer.cc(420)] Applying internal delay of 98 blocks.

[6336:3896:1113/203223.730:WARNING:block_processor.cc(153)] Reset due to render buffer api skew at block 93

Let me know what else I can provide for testing from this end. Thanks!

-Al 
peah@ We have many customers affected by this issue. Can you think of any possible workarounds for it? (other then using different headset or browser as it's not an option for many).
Cc: gustaf@chromium.org
Blockedon: 895338
Thanks for reporting this! And thanks for the good recording which clearly shows why the issue occurs. 

The cause for this behavior is a bug, or rather a design flaw, in AEC3.

What is happening is that the API call jitter is much larger on this device than we've seen before and constantly exceeds the maximum supported limit. In numbers this means that the headsets constantly, in an alternating manner, pushes 150 ms of data to the WebRTC audio processing module (APM) in one go and immediately after pushes 150 ms of render data in one go to the APM. 

As the AEC3 design choice is to support a maximum 104 ms (which is lower than 150ms) it constantly resets. Since the API jitter behavior is fully periodic, the resets are fully periodic as well and the effect is the choppy behavior of the audio experienced in this issue.

This issue is partially/mostly fixed in M71 and fully fixed in M72 ToT. To fully correct the issue a merge request of the  issue 895338  has been made for M71.
If the merge is granted, this will mean that the issue is fully fixed for M71.

Currently, for M70 it is not possible to fix the issue as M70 Stable is already rolled out. However, running M71 Beta, or M72 Canary/Dev should work fine.


@peah@chromium.org, thanks for all your effort in getting to the root cause. This AEC3 flaw regarding 104ms, do you know which exact version of Chrome this was introduced?
Status: Started (was: Assigned)
Adding to peah's post:

We are working to get this fixed in the next stable version of Chrome, M71.

As a work-around for now, you may want to try to disable the AEC for those particular headsets (if you have that information). Setting the constraint googEchoCancelation = false will turn off the echo canceller (don't use the echoCancelation constraint, which turns off _all_ front-end processing). Since these headsets have fairly good separation between speaker and mic, the echo seems to be very faint (at least in the recordings you provided). So, going without an AEC is an option. However, you must not turn it off blindly, only if you know that one of these headsets are used.


That design flaw/assumption has been there for a very long time, probably since M66 or M67, and we've seen no previous reports with issues on it. However, AEC3 did not reach Stable until M69 so it may be that you have not been hit by the issue before now?

@Hlundin @Peah
I would like to start testing while still onsite with a customer today. 
Should I expect better results testing with:
Version 71.0.3578.53 (Official Build) beta (64-bit)

Still seeing large fluctuations on the JitterBuffer in Internals on that version. Just want to make sure that is the right next step from my side. 

And thanks for all the help!
@19 the issue for all examples I have seen only occured on or post Oct 24th 2018. However the customer I am with currently has been suffering from some underlying issue for the better part of this year. I'd be curious if we are just seeing the true fallout recently.
The fix is not yet merged to M71. If you go for Chrome Canary or Dev, you should get M72 which has the fix.

Also, to ensure that you get the "problematic" code branch, open up chrome://flags and make sure that "WebRTC Echo Canceller 3" is enabled.
@22 Thank you for the clarification. Do we have a timeline on the M71 merge for beta? Just trying to set some expectations, even if ballpark possibilities. Thanks again!
Re #20:
Regarding the jitterbuffer fluctuations, I guess those could be related to the call-order of 150 ms that is seen? 

hlundin@,WDYT, would receiving 150 ms in one go, and having 150 ms data requested in one go have that effect on the jitterbuffer?

Yes, requesting output audio from the jitter buffer in blocks of 150 ms will definitely have an effect on the jitter buffer size and latency. This translates to an equivalent network jitter (essentially packets only coming in bursts every 150 ms, and then nothing in between).

The timeline for the merge of the fix is dependent on first actually getting merge approvals: see  issue 895338 . After that, it will be included in the next beta release. As you can see from https://chromiumdash.appspot.com/releases?platform=Windows, beta releases happen about once a week, so there is a fair chance next week's beta will include the fix.

M71 is expected to go stable early December, per https://chromiumdash.appspot.com/schedule.

M71 merg is approved, pls merge ASAP - https://bugs.chromium.org/p/chromium/issues/detail?id=895338#c6. Thank you.
@25 @Hludin
Thanks for the that. Pulled down Version 72.0.3611.0 (Official Build) canary (64-bit)
Still seeing fluctuations in there as well. Ran through headsets mid call to show variances. 

Apologies for the push from my side. Impact is wide spread and causing significant issues for our customers. I will be onsite for the remainder of the day with a customer who can replicate on the standard M70. Should we need any additional data points for M71 Beta or M72 Canary please let me know. 
CanaryJBFlucs.png
40.1 KB View Download
Sorry jumped the gun here...

Canary M72 with WebRTC Echo Canceller 3 moved to ENABLED seems to have much better results. Woho!

FlagEnabled.PNG
12.7 KB View Download
Great that you are seeing improved results. However, I'm not sure the jitter buffer fluctuations are expected to be mitigated with the fix. The quality of the outgoing audio is expected to improve massively over the horrible examples you shared yesterday.
Thanks for the great diagnostic work, and quick solutions, everyone! 

One question I have is why is this issue only manifesting itself on Windows 10? If the issue is with AEC in general, why wouldn't it also crop up on other versions of Windows or on Mac OS?
@29 Hlundin,
Just did some additional tests, and had one way audio, chime distortion, and still the fluctuations of JitterBuffer. 

Using a known affected headset on Canary M72 with the flag enabled. Will gather more examples on it and post back.
Re comment 30: This is what we are wondering too. My guess is that it has to do with how the OS or Chrome interacts with the headsets. Maybe it is opened with smaller buffer size on Mac.

I've ordered the Logitech headset to investigate this. We'd like to understand this, since using 150 ms soundcard buffers is in and of itself a bad thing. It adds 150 ms to the mouth-to-ear latency, deteriorating the conversation quality.
can someone please clarify the state of AEC3? I have not seen a "we are rolling out AEC3 widely" in the release notes so was under the impression this was still behind a flag 
peah@ thanks for all the work on it so far!
What is the best way to track when the fix gets merged to 71? We would be more comfortable suggesting our customers to update to Beta rather then Dev/Canary version of Chrome.

I see above that albrook..@ was still experiencing some issues with Canary M72, wondering if it is canary instabilities or the fix is not quite ready. 
@34 The issues I ran into on M72 Canary are strange. No audio (youtube, spotify, etc) at all when I use certain headsets. Oddly enough it happens with the headsets that were affected by the same issue this thread was for. No issues with sounds outside of browser. Like system dings or audio file tests. 

However the M72 Canary issues were on the audio towards the agent from the browser and not the agents audio into the browser. So id say it is likely unrelated unless im told otherwise by someone on the other side here.

JitterBuffer spikes existed in all versions when using the headsets. I would see it flatline on some calls due to no audio coming back. Strange, but I couldn't get enough tests/data points to be conclusive. 

The M71 next update following the weekly deloy history looks to be around next Weds the 21st. If it makes it out before Thanksgiving I guess. We are discussing internally on the best suggested steps for our customers. 

Thanks all.


Status: Fixed (was: Started)
fippo@: The status of AEC3 is as follows. It has for a long time (several milestones) been activated for a set of users on non-stable Chrome channels.

As of M69, we started activating it for a subset of users on Chrome stable as well. It is still in experimentation.

Re: the other audio issues, my guess is that you were hit by unrelated Canary instability. If you're up for it, please file a separate bug (with variation hashes).

I'm going to mark this as fixed now. The merge to M71 is happening now, and will be in the next beta release.

For the issue with the very large soundcard buffer with these headsets, I'm opening up a separate tracking bug.
hlundin: thanks! I'll put "you are not going to roll out AEC3 without telling developers that this happens" on the agenda for my next visit.

It would be great to have *something* in the release notes so that if people in the field experience weird issues they have some hints about what might cause it.
@36 I'd be curious to hear the rational behind that call. But moreso, the criteria for what subset of users were chosen in what time frames. This seemingly small experimental feature caused widespread intermittent failures for a large portion of our customers for weeks now. It continues to do so as we await the next beta release. 

I am just trying to get answers for questions that will ultimately come from both my customers and executive board. If this is not the place, where can we have that conversation?

Al
Cc: blum@chromium.org
+niklas
if you have slides about AEC3 you will probably get audience questions about this issue at Krankygeek.
hlundin: thanks for rolling out the fix in the next beta release! can you please give any guidance as to when it may happen? i need to know what expectations to set with our customers.
FYI: The large buffer size for these headsets is tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=905969.
PSA: As discussed above, the issue reported in this bug was specific to the experimental AEC3. The experiment is currently running for a part of Chrome Stable users, in addition to non-stable.

*There is a way for application developers to override this experiment* by using the Origin Trial announced in this blog post: https://developers.google.com/web/updates/2018/06/more-native-echo-cancellation. Setting echoCancellationType:browser will force the client back to the legacy AEC. (While this Origin Trial is mostly focused on experimenting with native echo cancelation, the new API parameter is also useful for forcing to legacy browser AEC.)

However, if you do find problems with AEC3, please, report the problem by filing a bug at https://bugs.chromium.org/p/webrtc/issues/entry. Please, include all the information from chrome://version, including the "Variations" hashes at the end. It is also very helpful to get a recording of the issue, as was done for the current issue.

Status: Verified (was: Fixed)
FYI: Chrome 71.0.3578.62 was released to the Beta channel yesterday (Nov 20). That release contains the fix discussed in comment 25.

We have verified it on the official Beta just now, using the Logitech Dual H820e headset.

If anyone can test the Jabra headsets, please, drop a line here to tell us if it worked.
@43 Thanks HLundin. I have asked some of my customers to verify, but given the holiday here stateside, we are likely to have minimal responses until next week.

Can you confirm for me please. Is there a fix itself to the way AEC behaves, or is the fix having the EchoCancellation toggle disabled by default? What are the thoughts around the JitterBuffer fluctuations?

Also would still love to learn more on how an experimental feature was enabled on the stable release. Will need to put a wrap on things on the customer facing side of the house. Anything you can provide details on timeline/rollout/selection process will make my life immeasurably easier! 

Thanks for the update and work!
-Al
hlundin: a question about the aec dump...

in the zip file from #8 there is a audio_debug.1220.aec_dump.1 which can be unpacked using the unpack_aecdump tool. This contains
* input_1.wav is the unprocessed signal from the microphone
* ref_out1.wav is what is going into the opus encoder
* and reverse1.wav is what is played out
and ref_out1.wav sounding horrible while input_1.wav is great allowed you to pinpoint this to the processing? 

Are the offline tools you mention in #11 available in a similar way as the good old video_replay tool?
Question to the Chrome team. Several of our people who were able to reproduce the issue before November 20 were able to verify the fix that went into Chrome beta on November 20 (Chrome 71.0.3578.62). They saw the issue before fix, but not after the fix. So the fix worked! So far so good.

However, they also stopped being able to reproduce the issue in Chrome stable. We have not heard any reports since November 22, and can no longer reproduce the issue in Chrome stable. Did something happen in Chrome stable as well? Was the experiment stopped/altered, or some other changes rolled out?

We would like to confirm that this issue is fully put to rest, so need to explain the above oddity.

Thanks!
ggraudins@: We concluded the Windows experiment for M70 Stable, and will resume again in M71 Stable.

If you would like to verify locally, you can always force AEC3 on/off in chrome://flags by controlling "WebRTC Echo Canceller 3".

Has anyone experienced the same in Mac OS Chrome Version 70.0.3538.110 (Official Build) (64-bit) ?
This is not known to us. The OP says it was not seen on Mac, and the underlying issue tracked and fixed in https://bugs.chromium.org/p/chromium/issues/detail?id=905969#c22 was specific to Windows.

If you experience issues, please, open a new bug, and share diagnostic recordings as described in https://bugs.chromium.org/p/chromium/issues/detail?id=905083#c6. Thanks!

Comment 50 Deleted

Comment 51 Deleted

I experience choppy robotic microphone capture on Discord (based on Chromium/Electron) on Windows 10, using a USB Focusrite 2i2 audio capture device. It'll capture fine for a while, then it'll "break" and remain robotic until I reset the USB device, which will fix it for a while.

The problem seems worst with lower ASIO buffer sizes (128/256). If I increase the buffer size to 512 the problem seems to go away (or occur so infrequently I have not noticed). 

This problem does not occur with any other capture app on the same PC at any ASIO buffer size. 
Was this on Discord running in the browser (Chrome) or was it the Windows 10 Discord app?
Windows 10 discord App. (which is based on Electron / Chromium)
Labels: -Pri-1 Pri-2
Have you tested this on Discord running in the browser? Is the problem there as well?

Since the Discord app is based on Electron/Chromium the presence of the issue there could be due the version of Chromium used in the app. Is it in anyway possible to check what version of Chromium was used?
I have seen this kind of (microphone capture quality) issue in discord in the browser (a long time ago), but it isn't something I do very often, so I have no idea if it's the same issue or something else.

I asked Discord support, but unfortunately, they "don't make [the electron and chromium version] public". Seems like they are hurting themselves there, but ohh well. 
Hello David,

Discord app uses customized version of WebRTC (currently based on M65) and does not use the one included in Electron. We use audio device module provided by WebRTC. So I am pretty sure that this is a different issue, I will directly follow up with you.

Comment 58 by peah@chromium.org, Jan 16 (6 days ago)

The old version of Chrome for the Discord app would explain a different behavior.

Comment 59 by peah@chromium.org, Jan 16 (6 days ago)

Status: Fixed (was: Verified)
I think this issue can be closed now.

M71 has landed and AEC3 is fully launched. The problem of choppy/robotic audio is no longer present, but if there is need, please feel free to reopen the issue.

Thanks everyone involved for raising the issue and adding very actionable data!

Comment 60 by peah@chromium.org, Jan 16 (6 days ago)

Status: Verified (was: Fixed)

Sign in to add a comment