niklase@ - can you try capturing an aecdump via chrome://webrtc-internals and determine if the incorrect pitch and glitches are audible in the output recording?

Anyone else have any ideas on how to proceed with this issue?

Well, I suggest to try to reproduce and narrow down.

I can't repro on Linux, Chrome 49.0.2623.87.

Niklas: Is it consistent for you?

Ping

niklase: can you provide more info?

Sorry, monorail and my spam filter have not been friends... Still repros, attaching AEC dumps

Deleted: audio_debug.23938.source_input.1.pcm 2.3 MB

audio_debug.23938.source_input.1.pcm 2.3 MB Download

Deleted: audio_debug.23938.aec_dump.1 7.3 MB

audio_debug.23938.aec_dump.1 7.3 MB Download

grunell: can you have a look and/or check with the audio team?

I can repro this consistently on Linux and ChromeOS. Haven't tried other platforms.

Tried this now on mac, and fwiw this doesn't seem to happen there.

Olga is looking at this.

Looks like the bug is caused by this CL https://codereview.chromium.org/1687213002:
TrackAudioRenderer::Render() was not updated, so it interprets frame delay as a delay in milliseconds.

... and it affects all non-peer-connection media streams.
... and exists on all the systems
 I'm not sure why it is audible on Linux/ChromeOs only, looks like the shifter compensates better on the rest of the systems. Probably it depends on the actual input/output clock drift value, which the shifter is meant to compensate for.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8fc0d951347d29e48a2241173383657869cf506e

commit 8fc0d951347d29e48a2241173383657869cf506e
Author: olka <olka@chromium.org>
Date: Fri Apr 15 15:03:54 2016

1) Fixing TrackAudioRenderer::Render() to interpret the second parameters as delay in frames, not in milliseconds.
2) Changing output buffer size back to "optimal". It was recently changed to use output buffer size in milliseconds,
but this does not make much sence, because system (well, at least linux) provides default size in frames and does not care about milliseconds.
For example, it can provide default values of 512 for any sample rate.

BUG= 596174 

Review URL: https://codereview.chromium.org/1891183002

Cr-Commit-Position: refs/heads/master@{#387600}

[modify] https://crrev.com/8fc0d951347d29e48a2241173383657869cf506e/content/renderer/media/track_audio_renderer.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/374367f4db56082237201e8163ed1156a69d9805

commit 374367f4db56082237201e8163ed1156a69d9805
Author: mostynb <mostynb@opera.com>
Date: Fri Apr 15 20:12:22 2016

move track_audio_renderer.{cc,h} to private_renderer_webrtc_sources

This unbreaks the no-webrtc build after
https://codereview.chromium.org/1891183002

BUG= 596174 

Review URL: https://codereview.chromium.org/1888183003

Cr-Commit-Position: refs/heads/master@{#387688}

[modify] https://crrev.com/374367f4db56082237201e8163ed1156a69d9805/content/content_renderer.gypi

Your change meets the bar and is auto-approved for M51 (branch: 2704)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a83ec21846b7ccdf8a85f2c13b40ef12ea43e35c

commit a83ec21846b7ccdf8a85f2c13b40ef12ea43e35c
Author: Henrik Grunell <grunell@chromium.org>
Date: Mon Apr 18 11:44:10 2016

1) Fixing TrackAudioRenderer::Render() to interpret the second parameters as delay in frames, not in milliseconds. 2) Changing output buffer size back to "optimal". It was recently changed to use output buffer size in milliseconds, but this does not make much sence, because system (well, at least linux) provides default size in frames and does not care about milliseconds. For example, it can provide default values of 512 for any sample rate.

BUG= 596174 

Review URL: https://codereview.chromium.org/1891183002

Cr-Commit-Position: refs/heads/master@{#387600}
(cherry picked from commit 8fc0d951347d29e48a2241173383657869cf506e)

Review URL: https://codereview.chromium.org/1894103002 .

Cr-Commit-Position: refs/branch-heads/2704@{#88}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/a83ec21846b7ccdf8a85f2c13b40ef12ea43e35c/content/renderer/media/track_audio_renderer.cc

Issue 595635 has been merged into this issue.

 Issue 551303  has been merged into this issue.

I tested with Chrome Canary on Windows and on Linux.
On Windows it indeed worked well, but on Linux (Ubuntu 14.04 LTS) the bug still exists.

ashercoren@: The fix is in Canary, but there is no Canary for Linux. For Linux, you'll have to wait until the fix hits the dev channel.

Thank you for the clarification. And thank you very much for the fix!

Just to update, verified the issue on Ubuntu 14.04 on Chrome Dev# 51.0.2704.19 and the issue still exists.
Navigated to the URL, "https://webrtc.github.io/samples/src/content/getusermedia/audio/" and observed that the audi is not yet clear.
Thank You.

The fix landed on 52.0.2710.0, so it should be available on the upcoming Linux dev release.

msrchandra@ - can you clarify what audio "is not yet clear" means? 

guidou@ - according to https://chromium.googlesource.com/chromium/src/+log/51.0.2704.7..51.0.2704.19?pretty=fuller&n=10000, the merge noted in comment #23 is in 51.0.2704.19. Can you download that version of Chrome internally (ask jansson@ if you don't know how to get it) and listen to the results yourself? I think 51.0.2704.19 is the next dev channel candidate, which is why msrchandra@ was testing it.

cc'ing msrchandra@ to answer #31.

@tnakamura -- Verified the issue on Latest Chrome Beta# 51.0.2704.22 and Latest Chrome Dev# 52.0.2716.0 on Ubuntu 14.04.
They are no glitches (high and low pitch) in the audio, but there is a continuous buzz sound throughout the audio.
Please let me know if anything else is required.
Thank You.

msrchandra@ - thanks for the follow up! I think what you're hearing is unrelated, but can you file a new bug so we can investigate? While you have that test page open, please also obtain an audio recording:

1) Open a new tab to chrome://webrtc-internals/
2) Expand the "Create Dump" section
3) Fill in the "Enable diagnostic audio recordings" checkbox. A file save dialog will appear.
4) Keep the default file name, and select any local location to save the file to.
5) Resume your test. Once you've confirmed that you still hear the buzz sound, let the recording continue for a few more seconds, then return to the webrtc-internals tab.
6) Uncheck the "Enable diagnostic audio recordings" checkbox to stop the recording.
7) In the folder you selected, find the recording files. One file should be named audio_debug.XXXX.aec_dump.Y, where XXXX and Y are somewhat random numbers. You may also see audio_debug.XXXX.source_input.Y.wav.
8) Attach both files to the new bug. Please cc: me and srnarayanan@, and we'll triage it.

niklase@ - can you get the current beta channel build (51.0.2704.22) and see/hear if the original problem seems fixed?

msrchandra@ - do we have any updates on this? can you please retry in the latest beta 51.0.2704.36 with steps in #34 above and let us know if you still see/hear the original problem, or the "buzz" sound as in #33? 
Thanks!

I ran local tests in Linux per the original repro steps, and it sounds good in the latest Beta 51.0.2704.36

Hello again.
Unfortunately the it looks like the celebrations were too early.
The bug reappeared again.
Go to https://jsfiddle.net/2w6jmas3/1/ and click on play. The bug doesn't always happen, so if the sound is good click on stop and play until you hear the bug.

I'm using the latest stable version of Chrome. Both on Linux and on Windows.

This is a major issue for us.

I can confirm that I do hear it on Linux 51.0.2704.84

I haven't found any changes between 51.0.2704.36 and 51.0.2704.84 those could cause it.
Probably WebAudio issue? Looks like issue 595635 better reflects the problem, so closing this one.

Is it possible that the issue was never truly fixed? Maybe we didn't test
enough with 51.0.2704.36?

Hi,

While trying to study further some related issue (https://bugs.chromium.org/p/chromium/issues/detail?id=766198), I found this one which is clearly the same.

It seems that Web Audio and WebRTC interaction has never been fixed and users still suffer from an incapacity of choosing the audio output on Chrome.

We'd really like to help for this is a totally blocking issue for our product.

Thanks to all

hameshiv@ - not sure what "incapacity of choosing the audio output on Chrome" is?
Could you find a relevant bug and add a comment on it with info you have?

This particular bug is a very specific Linux issue which was fixed - and it is closed now.

Hi Olka,

Issue 766198 is the most accurate thread about this issue. 

It is indeed a different but similar symptom, causing the audio to slow-down according to the CPU performance, which started to happen from Chrome 60.

I invite you to join the discussion there, and check if it's a webaudio issue, webrtc's or both.

Thanks