Tested this issue on Mac OS 10.12.6 using chrome latest stable #60.0.3112.101 by following steps mentioned in the original comment. Observed the audio plays clear without any distortion while interchanging the hardware.

Could you please elaborate step-6? After step-5 reloaded the page and observed the sample rate displays 44100 without any change. 

Thanks!

I believe this works on Mac because the OS takes care of the necessary magic.  A few years ago, I could start a webaudio page, then change the sample rate of the default audio device and there would suddenly be no sound.  This changed at some point when I upgraded to a new macos version.

It would be a pretty big refactoring of WebAudio code to allow sudden changes in sample rate.  Many nodes have the sample rate embedded within the node at construction.  An alternative would be for WebAudio to keep the existing graph but resample the output to the new hardware rate.  This is doable, but that would suddenly cause a possibly huge change in latency due to the resampling.

@nyeramilli I think I may have unnecessarily complicated the steps.  I just wanted to show that it works fine at both sample rates under normal circumstances.  It is only if you load the page with one sample rate and then change the sample rate without reloading the that you run into issues.  Even then, it only seems to be an issue if you are moving from a higher to a lower sample rate.  ie. 48000 down to 44100

Clarified steps:

1. Have an audio interface with a 48k sample rate configured and make sure that your built-in audio device is configured to 44.1k (built-in input AND built-in output via Audio Midi Setup application).

2. Set your default audio input and output device to be the 48k interface in your audio system preferences.

3. Load test page and 48000 should be listed as the initial sample rate.

4. Press play an hear a clear sine wave through the interface.

5. Without reloading the page - Plug in earbud/mic combo headphones into the built-in jack.

6. Press play and you should hear a distorted sine wave.

In my case I am using a Komplete Audio 6 audio interface.  I have also successfully recreated this using display audio on this monitor set to 48k (https://www.amazon.com/Acer-H277HU-kmipuz-27-Inch-speakers/dp/B01B64O3M4/ref=sr_1_7?ie=UTF8&qid=1502985898&sr=8-7&keywords=acer+27+inch)

I run an audio recording SaaS and I can confirm that this is a relatively rare but still wide spread issue (mac and pc) as I get regular support requests regarding it.  The general cause is that they load the page without their headphones plugged in and then plug them in, potentially changing the sample rate ,and press record.  It took me months to even figure out a way to recreate the problem.

I have attached the specs for my mac in case that is helpful

Deleted: Screen Shot 2017-08-17 at 9.54.23 AM.png 26.6 KB

	Screen Shot 2017-08-17 at 9.54.23 AM.png 26.6 KB View Download

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

@rtoy I am able to reproduce the problem on a new and fully upgraded mac.  

As far as I can tell, automatically resampling the the output to the sample rate of the Audio Context is the chosen solution here: https://bugs.webkit.org/show_bug.cgi?id=154538#c4

The crux of the issue seems to be this: https://bugs.webkit.org/show_bug.cgi?id=154538#c11

This would match my experience as I can only reproduce the problem if I am moving from a higher to a lower sample rate. ie. 48k to 44.1k.

If it really isn't feasible to resample the audio to the audio context's initial sample rate or to update the sample rate, there at least needs to be an event to let the developer know that there is a mismatch and to prompt a re-initialization of the web app.

Thanks for the help on this.

I should also add that this issue affects both the input and output audio.  You will hear distorted audio being played back by web audio and the distortion is also present in the audio received via getUserMedia.

For the record https://bugs.webkit.org/show_bug.cgi?id=154538#c14 has
the proposed fix in
https://bugs.webkit.org/attachment.cgi?id=272280&action=diff, which
basically implements a FIFO. Chrome already has a FIFO to handle the
possibility that the device asks for blocks of data that are not
multiples of 128. (Needed originally to support Windows).

It's certainly possible to resample, but that can add additional latency or distortion (depending on how good the resampler is).  For some applications, this would be bad.  Firing an event on a sample rate change would require a change in the spec.

> Chrome already has a FIFO to handle the
> possibility that the device asks for blocks of data that are not
> multiples of 128. (Needed originally to support Windows).

Does this mean that there shouldn't be distortion when the underlying sample rate changes?  Or are you saying that the most feasible solution is already in place but distortion is to be expected in these edge cases?

No, that doesn't mean that distortion is fixed. It's just a note that what webkit is adding to fix the issue there is already supported in some way in Chrome.

We still need to investigate why this is happening.  (I need to get devices that have different sample rates.)

rtoy@,

Friendly ping to get an update on this issue as per C#10.

Thanks in advance..!!

@rtoy -- A friendly ping. Is there any update on this issue.
Thanks!

Sorry for the delay!

No updates on this, but I think we'll investigate this when we add support for resampling in the AudioContext. See issue 432248.  When that's implemented, we can do the necessary resampling when the HW rate changes.  (Still think that should be done at the OS level, not application.)

mac triage: marking this Assigned.