New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 882211 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
OOO
Closed: Oct 9
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-10-10
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Strong noise on the websdr page, does not respond to tab controls

Reported by darko....@gmail.com, Sep 9

Issue description

UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Example URL:
http://sdr.radioandorra.org:8901/  http://websdr.pzk.pl:8901/ http://grimsbysdr.ddns.net:8073/

Steps to reproduce the problem:
1. Go to web page http://sdr.radioandorra.org:8901/
2. wait and pray
3. ...and wait ... and wait ...

What is the expected behavior?
Light noise when there is no signal, intermittent conversation when set to radio frequency with signal.

What went wrong?
Strong noise on the websdr page does not respond to tab controls.
Rebooting your web browser does not help. After some time, normal sound appears sometimes.

Did this work before? Yes All Chrome /Chromium version before 69

Is it a problem with Flash or HTML5? N/A

Does this work in other browsers? Yes

Chrome version: 69.0.3497.81  Channel: stable
OS Version:  Debian 4.9.110-3+deb9u4
Flash Version: 

Contents of chrome://gpu: 

Graphics Feature Status
Canvas: Software only. Hardware acceleration disabled
Flash: Software only. Hardware acceleration disabled
Flash Stage3D: Software only. Hardware acceleration disabled
Flash Stage3D Baseline profile: Software only. Hardware acceleration disabled
Compositing: Software only. Hardware acceleration disabled
Multiple Raster Threads: Disabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Disabled
Rasterization: Software only. Hardware acceleration disabled
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Synchronization: Enabled
Video Decode: Software only. Hardware acceleration disabled
Viz Service Display Compositor: Disabled
WebGL: Disabled
WebGL2: Disabled
Problems Detected
GPU process was unable to boot: GPU access is disabled in chrome://settings.
Disabled Features: all
Raster is using a single thread.
Disabled Features: multiple_raster_threads
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Viz service display compositor is not enabled by default.
Disabled Features: viz_display_compositor
Skia renderer is not used by default.
Disabled Features: skia_renderer
Skia deferred display list is not used by default.
Disabled Features: skia_deferred_display_list
Version Information
Data exported	2018-09-09T07:46:10.287Z
Chrome version	Chrome/69.0.3497.81
Operating system	Linux 4.9.0-8-686-pae
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/032b3ca19e9af20182f9bd03deefc0faf4695558/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/032b3ca19e9af20182f9bd03deefc0faf4695558/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	unknown hash
2D graphics backend	Skia/69 e110fd1ebd2d559838c49a8821ebf18986bd6ec2-
Command Line	/usr/lib/chromium/chromium --disable-pings --enable-remote-extensions --ignore-gpu-blacklist --media-router=0 --no-default-browser-check --show-component-extension-options --flag-switches-begin --autoplay-policy=document-user-activation-required --flag-switches-end
Driver Information
Initialization time	0
In-process GPU	true
Passthrough Command Decoder	false
Sandboxed	false
GPU0	VENDOR = 0x0000, DEVICE= 0x0000
Optimus	false
AMD switchable	false
Driver vendor	
Driver version	
Driver date	
Pixel shader version	
Vertex shader version	
Max. MSAA samples	
Machine model name	
Machine model version	
GL_VENDOR	
GL_RENDERER	
GL_VERSION	
GL_EXTENSIONS	
Disabled Extensions	
Disabled WebGL Extensions	
Window system binding vendor	
Window system binding version	
Window system binding extensions	
Window manager	Openbox
XDG_CURRENT_DESKTOP	LXDE
GDMSESSION	LXDE
Compositing manager	No
Direct rendering	Yes
Reset notification strategy	0x0000
GPU process crash count	0
System visual ID	0
RGBA visual ID	0
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	Software only
R_16	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	Software only
BGRX_8888	Software only
BGRX_1010102	Software only
RGBX_1010102	Software only
BGRA_8888	Software only
RGBA_F16	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
Display(s) Information
Info	Display[7515990809278291] bounds=[0,0 1440x900], workarea=[0,0 1440x900], scale=1, external.
Color space information	{primaries:INVALID, transfer:INVALID, matrix:INVALID, range:INVALID}
Bits per color component	8
Bits per pixel	24
Video Acceleration Information

Firefox works fine, Vivaldi works fine, only  Chrome / Chromium have problem.

Mourning.
 
websdr_recording_2018-09-09T07_57_12Z_7028.2kHz.wav
1.3 MB Download
Labels: Needs-Triage-M69 Needs-Bisect
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.).

Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
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...!!
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!

Project Member

Comment 5 by sheriffbot@chromium.org, Sep 11

Labels: -Needs-Feedback
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.

Labels: -Needs-Bisect M-69 Target-70 Target-71 M-70 FoundIn-71 FoundIn-70 Target-69 FoundIn-69 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
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...!!
Components: -Internals>Media Blink>WebAudio
Appears to be WebAudio and not <audio> or <video>
Labels: Needs-Feedback
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?
Status: Available (was: Untriaged)
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
Owner: rtoy@chromium.org
Status: Assigned (was: Available)
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.
Status: Started (was: Assigned)
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.
Project Member

Comment 22 by bugdroid1@chromium.org, Oct 1

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.
NextAction: 2018-10-10
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.
Status: Verified (was: Started)
Thanks for testing!

Closing as fixed.  Sorry for the trouble.
The NextAction date has arrived: 2018-10-10

Sign in to add a comment