It seems this problem is not in the browser's audio (media) engine, but in the javascript engine.

Background: I'm the developer of the software running these WebSDR sites.
I tested this by modifying the server side to send essentially uncompressed data; with that, the problem didn't occur, so seemingly the error only occurs when the browser executes the javascript code which does the audio decoding/decompression (including lots of bit shifting etc.).

Tried testing the issue on ubuntu 14.04 and mac 10.13.3 using chrome reported version #69.0.3497.81 and latest chrome version #71.0.3547.0.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to http://sdr.radioandorra.org:8901/
2. Observed that noise got generated on the websdr page and on clicking the mute button did not mute the tab. Same behavior is observed from M-60. Whereas in firefox, noise got generated on the websdr page and on clicking the mute button muted the tab.

darko.god@ - Could you please check the attached screen cast and please let us know if it is the issue being observed by you. This will help us in triaging the issue further.

Thanks...!!

Deleted: 882211.mp4 2.0 MB

	882211.mp4 2.0 MB View Download

These tab controls are in Chrome for linux only for decoration. They do not work on other sites that have sound.
An example is https://www.youtube.com/watch?v=tR6ULMWYct8

This is not the main problem. The problem is "white noise" without control and no useful sound.

There is a way to obtain useful sound bypass:

Go to the websdr web site, you will hear a strong noise.
Click on the mute checkbox, wait a second, and click again on the same checkbox.
A normal signal from the speaker appears. (Sometimes)

By the way, there is no sound in your attachment, Windows10 and Debian 9 have no sound, just a picture.

Thanks!

Thank you for providing more feedback. Adding the requester to the cc list.

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

Perhaps an easier test case is this URL:
  http://websdr.ewi.utwente.nl:8901/?tune=198am

The tune parameter tunes this receiver to BBC radio on 198 kHz. So if all is well, you hear normal radio programming (voices, music, whatever), while when the problem occurs, you get loud white noise.

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome reported version #69.0.3497.81 and latest canary #71.0.3549.0.
The issue seems to be very inconsistent in nature. Hence, it won't be possible from our end to provide the bisect results.
Hence, marking it as untriaged and removing Needs-Bisect label. Requesting someone from  	
Internals>Media team to please help us in assigning it to the right owner.

Thanks...!!

Appears to be WebAudio and not <audio> or <video>

The JS library uses Convolver and ScriptProcessorNode, but none of them are changed recently. Also I am not sure what's the expected behavior and what's broken.

Am I supposed to hear the radio broadcast from the link in #6? I heaed all white noise once and then I could hear the news after reloading the page.

Yes, the link in #6 should give you a radio broadcast. If you heard white noise, that's the problem occurring.
Unfortunately, whether it occurs seems to depend a lot on the audio that happens to be broadcast. The problem can occur within seconds, or not at all for hours.

My impression (I'm the developer of these WebSDR sites) is that the error is not related to the webaudio engine, but happens inside a bunch of JS arithmetic code that does audio data decompression.
Testing tonight I thought I had a deterministic example to reproduce it, by substituting a recorded data sequence that reproduces the problem instead of unpredictable live radio audio, but unfortunately that wasn't quite reproducible either.

Console has an error:

Uncaught DOMException: Failed to set the 'buffer' property on 'ConvolverNode': Cannot set buffer to non-null after it has been already been set to a non-null buffer

Per the spec, you can't change the buffer of a convolver node once you set it to a non-null value.  This was implemented a little while ago.  I suppose this could cause the noise if the convolver is being used to implement the radio filtering to isolate the desired radio band.

Hmm. I have not seen that error in the console. So it might be flaky?

Yeah, I didn't always see the message, but when I do, it happens twice.

I did some more testing, and that error message indeed seems crucial, albeit it in a roundabout way.

I think the following happens. The uncaught exception interrupts my JS code while it is decoding an incoming data packet; consequently, the rest of the packet is not decoded, leaving behind an inconsistent state, which causes subsequent data packets to be misinterpreted, producing the white noise.

Is this exception new in version 69?

My code indeed intentionally sets the buffer of the convolvernode, in order to change its impulse response on the fly. As far as I can tell, that used to be allowed by the spec (back when I wrote this code, in 2013 or so), and worked fine.

Yes, this is new in 69.  The change in the spec was a while ago too. (I'd have to look at the PRs to find out when.)  The solution is to create a new ConvolverNode when you change the response, disconnecting the old convolver. I know this is not great.

I found this discussion about the WebAudio API:
   https://github.com/WebAudio/web-audio-api/issues/122
The third-last posting there (dated May 14, 2015) decides:
   "Resolution: 1. Allow buffer property of ConvolverNode to be set at will, with guidance in the spec clarifying that glitching may occur."

The current spec obviously says the opposite of what was decided there, so there must have been an even later change to the spec (about which I haven't found discussion).

I must say that I find it odd that an API which people had been coding to for several years (at least since 2013), suddenly (2015 or later) gets an extra restriction that wasn't there previously, particularly since this new restriction forbids something that was working just fine (apart from minor audio glitches that often went unnoticed), so developers actually used it.

Is there any hope this restriction can still be removed?
Or at least that Chrome deprecate it in a more gentle way, e.g. by only warning about it rather than throwing an error?

Thanks for looking that up.  Not sure what happened, but I filed a new issue on the spec to clarify what the intent really was. See https://github.com/WebAudio/web-audio-api/issues/1762

We discussed the issue in the WebAudio group and decided to revert this change (https://github.com/WebAudio/web-audio-api/issues/1762#issuecomment-425160944)

Setting the buffer more than once is allowed; you're responsive for any glitches that that might cause.

I'll do this soon.

That's great! Thanks a lot for handling this issue with the WebAudio group!

B.t.w., I've been wondering what kind of glitches are meant here.
When one instantaneously changes the impulse response of a filter, it's natural to expect that the filter output signal has a jump at that moment; this follows logically from how a convolution is calculated as a weighted sum of previous samples, where the weights suddenly change.
Is such a jump the (only) kind of glitch that should occur?
Or are more serious (less naturally expected) types of glitches possible?

Yes, there's the glitch from the obvious change of the filter.  But they're might be others; I haven't checked to see if they happen.

Chrome's convolver uses FFTs so there can be quite a bit of delay before the buffer is actually switched because it takes time to compute the FFTs of the response.  Also, Chrome spins up to 3 threads to do the convolution and I'm not sure what happens to those threads (and the resulting data) when you switch buffers.  Any one of these could cause funny glitches.

CL available, but waiting for approval of the spec change before landing.  This very likely won't make it into 71.  It will not be merged into earlier versions  either.

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

commit f4fd7ba2801d56d87dd3989787528770ae259443
Author: Raymond Toy <rtoy@chromium.org>
Date: Mon Oct 01 22:21:52 2018

ConvolverNode buffer can be set multiple times

It is valid to set the buffer attribute more than once.

As resolved in https://github.com/WebAudio/web-audio-api/issues/1762,
setting the buffer more than once is allowed.

This is a revert (mostly) of
https://chromium-review.googlesource.com/c/chromium/src/+/1077713

Bug:  882211 
Test: the-convolvernode-interface/convolver-setBuffer-already-has-value.html
Change-Id: Ie7f170883e6a6b2bfa7f14d89c74b72eebde3dac
Reviewed-on: https://chromium-review.googlesource.com/1249275
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595586}
[modify] https://crrev.com/f4fd7ba2801d56d87dd3989787528770ae259443/third_party/WebKit/LayoutTests/external/wpt/webaudio/the-audio-api/the-convolvernode-interface/convolver-setBuffer-already-has-value.html
[modify] https://crrev.com/f4fd7ba2801d56d87dd3989787528770ae259443/third_party/blink/renderer/modules/webaudio/convolver_node.cc
[modify] https://crrev.com/f4fd7ba2801d56d87dd3989787528770ae259443/third_party/blink/renderer/modules/webaudio/convolver_node.h

The fix should be in canary in a day or two.  It would be great if you could try this out when you get a chance.

I tried this out locally and I don't have any issues with any of the repro cases listed.

Hi, I am a sysop for one of the WebSDR servers affected by this issue. Many users have reported experiencing this and I have directed them to this discussion for updates. I can confirm that Canary Version 71.0.3572.0 (Official Build) canary (64-bit) does seem to have rectified the problem. Thanks.

Thanks for testing!

Closing as fixed.  Sorry for the trouble.

The NextAction date has arrived: 2018-10-10