I am able to repro this bug on all platforms(Win,CrOS, Linux,Android) except Mac. 
dale, can you take a look?

This is WebAudio.

I suspect this is caused by the buffer size used by WebAudio not matching whatever createMediaStreamDestination is using.

This is a very severe issue. Since streaming through an Audio Element is currently the only way to use the new feature of playing audio through a non-default audio device, this issue means that currently there is no real way to use a non default device.
Any idea when this could be fixed?

Oops.  c#3 is really about something else.  There are no scriptprocessors in the repro URL.  I can reproduce this.

This issue actually occurs not only with oscillator, but with every sound played via mediastream and media element.

There was also discussion about it here https://bugs.chromium.org/p/chromium/issues/detail?id=557185#c12

Is this going to be fixed in the near future ?

Apparently this bug is not new. I tested it on an old Chrome version (43) and the bug exists there as well.

My guess is similar to the comment #3. Any MediaStream/Element stuff tunnels the audio through the WebRTC counterparts, and the infrastructure (buffersize/samplerate) is quite different from WebAudio.

I suspect that this inconsistency is causing the issue here. Definitely need more investigation here.

Re #7:

Could you tell me why you have to use audio element to route the output from WebAudio?

We use it like that to output audio on non default output device (with setSinkId), since the setSinkId is not yet available for WebAudio.

This solution is mentionned here: https://www.w3.org/TR/audio-output/#h-no-change-to-spec

I think we would prefer to get the output selection working for WebAudio.  This is not to say we won't fix MediaStreamDestination, but allowing WebAudio to select the output device is a more general solution.

Device selection is currently under discussion for the WebAudio spec.

We agree that the WebAudio option is the more general and correct way, but
since you have already implemented the MediaStreanDestination option, won't
it be counter productive to give up on it?
Also, enabling the selection of a non default is something we have been
waiting on for a long time. Waiting for the WebAudio option could mean a
delay of many months for us.

Is there any update on this issue?

I found this in the latest Dev Channel release notes: "Fixing AudioBuffer params and channel layout bugs", with a reference to multiple bugs, and to this Review URL: https://codereview.chromium.org/1868983004.

Should this fix our issue as well? If so, when can we expect for it to be released in Stable mode?

You can download the dev channel (or the canary, if you do not want it to replace the stable Chrome) and test it by yourself.

Since it is included in Chrome 51 and Chrome 50 was just released, you can expect the fix to arrive to the stable channel in about six weeks.

I downloaded the dev channel and tested it out.
I couldn't reproduce the bug on Windows (which doesn't prove that the bug doesn't exist, as it was a fluky bug to start with), but I could on Ubuntu - the sound is still broken.

I believe this was fixed by https://codereview.chromium.org/1891183002.

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@: can you try the latest dev version of Linux (51.0.2704.19)? On my machine it works well.

I can confirm that Linux 51.0.2704.19 sounds fine.  It was previously very choppy.

This is a duplicate of 551303 instead of 596174

@guidou I can confirm that it now works well on Linux as well.
Thank you.

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.

let's track the problem in  Issue 596174 

And here we are again.
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 though.
Probably WebAudio issue?
rtoy@ - PTAL?

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

I'm unable to reproduce the originally linked issues. However, I strongly believe the audio playback issues are caused by nothing else than main thread load.

Although I'm unable to provide a demo at this time, it seems to very often happen when lots of oscillators and/or other audio sources are started in a short period of time.

To me it seems as if the system couldn't keep up with audio processing due to minor blocks on the main thread, and then keeps outputting detuned audio until it can catch up (usually a few seconds).

I am also unable to reproduce this using the example URL with Chrome 64.0.3282.71 (Official Build) beta (64-bit)

Hi, This defect is referenced in https://bugs.chromium.org/p/webrtc/issues/detail?id=5525. We are looking o support multiple calls through WebRTC and this defect seemed to be a blocker. Is this issue fixed in Chrome Ver. 64 ?

In addition to the routing issue described here, we've been dealing with a stability concern on WebRTC for a year. Please join this thread: https://bugs.chromium.org/p/chromium/issues/detail?id=766198