I added an event log, it happened 9 minutes into the conversation.  I have other dumps, but they are too large,

Just to clarify, this only happens using Chrome M51/M52, the G933 headset and on Windows 10?

Have you tried a different WebRTC based app like https://appr.tc? If that too sounds bad, could you try a different app like Skype?

Does it happen every time, if not how often?

WRT large log dumps, you could upload those to a cloud service and share them here.

Looking at that event log indicates that the network was good with 0 packets lost on the incoming stream and only 5 on the outgoing.

I tested on https://appr.tc this morning, and after 12 minutes, the problem began again.  I have reverted back to Firefox and appear.in

Is there anything I can provide?  Should I get full dumps from appr.tc?  or appear.in?  I can do a full debug starting around 8 minutes through to the issue of sound going bad.

Yes, this only Happens with M52, G933, and on Windows 10.  I can't get this to happen on other hardware, MacOSX, the H800 or the G930.

You could do an audio recording using the aecdump feature in chrome://webrtc-internals.

1. Browse to chrome://webrtc-internals in a separate tab
2. Reproduce the issue in a separate tab
3. Go back to webrtc-internals page and expand create dump then check the "Enable diagnostic audio recordings" box.
4. Leave it running for a few seconds and verify that you still hear the issue.

Attach the logs here or share via some cloud service.

Alternatively if you have a cloud service that allows huge files, you could start the recording at the beginning of the call and share it but do note that recording will be quite big.


Also, could you open chrome://media-internals/ and go to the audio tab and copy the contents of the different controllers and streams here (click on each button and copy the properties of each one, you can use the copy to clipboard button)?

Also, it's when doing the above steps, please make sure not to have other tabs open.

I realize this is lots of info and work but it will help to try to identify the issue, thanks for taking the time!

Also, is it fine in M53 and M54?

Thank you for providing more feedback. Adding requester "jansson@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I have done a recording, the issue starts someplace between 3:35 ~ 3:40 into the wav debug.

I have included an AEC_dump, and the event_log, it's 178mb compressed, and about 650mb uncompressed.

http://clownphobia.com/~anthony/artemis/debug.7z

Thanks, downloading now.

Also, have you tried in M53 and M54?

tlegrand@ grunell@ I've listed to the the recording and both the input0.wav and ...source_input.1.wav files have bad audio around 3:40 and onward.

This indicates that the audio is already bad when Chrome receives it, right?

Yeah, it seems like it.

But this doesn't happen with Firefox, or other headsets.  Regardless if it's webr.tc or appear.in , it's consistently happening with the Logitech G933.  If the input was bad, a refresh of the page would still have the issue, but a simple reload of the page (webr.tc or appear.in), the audio is fine for up to 9 minutes.


How/Where do I get m53 or m54?

Chrome is released in different channels, details here https://www.chromium.org/getting-involved/dev-channel.

To see which channel has which version go here: https://www.chromium.org/developers/calendar.

Ok, I tested with 53.x

And the URL is:
http://clownphobia.com/~anthony/artemis/2016-08-09.7z

The problem can be heard starting up at 23:10, and towards the end it sounds like everything is sped up, it's dropping a fraction of a second.  Why would the input be skipping segments?

If it was my microphone, it would be a straight timeline, but this is like 2x sped up, or in real time it's has gaps when my friends hear it.

I'm testing Version 54.0.2816.0 dev-m (64-bit)  later today, when I have someone to let me know when I sound horrible.

Regarding the question in Comment 12, "This indicates that the audio is already bad when Chrome receives it, right?": I'm not sure it does. If I remember correctly, there is still the chance somethings goes wrong right before we record. Henrik would know this, so I'm reassigning to him.

I tested with M54, with the same results, except it took longer than 9 minutes. I'm not going to upload that set of files unless asked for, they are getting big to store on my personal server.  Not something I want a link pointing to for a long time.

Re comments #12 and #16: that data is written first thing in the platform independent code (https://cs.chromium.org/chromium/src/media/audio/audio_input_controller.cc?sq=package:chromium&l=411). It could still be an issue in the platform specific Windows code (https://cs.chromium.org/chromium/src/media/audio/win/audio_low_latency_input_win.cc?sq=package:chromium&l=296)

Tommi, could this CL and its bug perhaps be related?
https://chromium.googlesource.com/chromium/src/+/b1d55f8e6b1d5e93d51966293fbc678361777277

Ping Tommi. Question in comment #18.

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

+Marina, Olga FYI

I'm on M61, and not experiencing these problems anymore, but I've been hearing other users with the same issue, using the same headset, but they have not submitted any bugs, and have not put any bug reports about it.


Regards-