I can reproduce this strange effect. What I hear is the second time the pitch of the oscillator is much lower than the first time.

@rtoy Do you have an idea of why this happens, and when it will be fixed?

I have no idea why this happens.  We don't normally give out timelines for when things will be fixed.

Here is another strange behavior: When connecting a permanent empty source node to the MediaStreamDestination, it fixes the issue. See here: https://jsfiddle.net/dLvLr0n7/

We had the same problem of non precise sound when connecting a media-stream-destination to an audio element. 
Will this bug be fixed in the near future? 

For something fun, use any of the test urls above and in a new tab do:

c = new AudioContext();
o = c.createOscillator()
o.connect(c.destination)
o.start()

Listen to the funny output.  Press the Toggle button in the test urls.  Wait several seconds or minutes.  The audio is constantly changing, and at some point, it's almost silent as if the audio from the two tabs are 180 deg out of phase.  But the audio comes back.

I suspect this is caused by the MediaStream stuff being driven by, basically, performanceNow time, but the audio is running on a different clock that is not synchronized.

I think  issue 335335  is relevant to this.  If so, this is outside the scope of WebAudio itself and is a much bigger issue.

Raymond,
The only reason we use the hybrid creature of a WebAudio graph connected to an Audio Element is that this is currently the only way to play the sound do an audio device other than the default device. This hybrid creature seems to cause multiple issues.
I beleive the abiltiy to set a sinkId for an AudioContext will fix these issues. Altohugh it is still in draft (https://www.w3.org/TR/2016/WD-audio-output-20161014/#audiocontext-constructor-argument), do you have plans to implement this in the near future?

We can't really launch this because it's not in the WebAudio spec yet. It's unlikely that the spec will get this changed this year, unfortunately.  But the good news that it's a relatively simple change to the spec, so it is useful, even if enumerateDevices can't do what we want to do.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

This issue still repro. the original repro url is also valid. 
Dale, do you want to take a look? or feel free to resolve it.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

I don't think this is WebAudio's problem. WebAudio doesn't do any resampling or sample-filling within the graph.

See the comment #7:

> Wait several seconds or minutes.  The audio is constantly changing, and at some point, it's almost silent as if the audio from the two tabs are 180 deg out of phase.  But the audio comes back.

This sounds like AudioShifter is kicking in for some reasons. Perhaps FIFO buffer size mismatch is happening somewhere?

olka@ WDYT?

What do we see in the traces (chrome://traces) for audio and webaudio categories?

Unfortunatly the repro code does not work on the latest Canary anymore. I need to fix it first before we can grab the trace.