Aargh.  The shiny drum machine demo also sounds bad with Chrome beta (70.0.3538.35) on Linux too.  I think that means the bisect is incorrect because the two WebAudio changes there aren't included in M70.

Yuck.

But Chrome 70 on OSX sounds fine.

That may be a different issue as I'd been running Chrome Canary fine last week and only this morning noticed that I was getting no audio in Soundtrap. So I'm fairly confident that this is confined to a recent version of Chrome 71, though of course I could have made a mistake.

I think we SHOULD test any significant CL against this "POP" template.

Weirdly enough, Chrome Music Lab plays okay. This really needs further investigation.

Maybe so, but I didn't think either of the CLs as "significant".  Let me try on my linux box with ToT with those two CLs removed....

I wonder if the drum machine gets confused on my linux box which doesn't have any midi devices attached.  The midi-synth sounds fine with ToT from this morning.

The roughly equivalent https://googlechromelabs.github.io/web-audio-samples/samples/audio/shiny-drum-machine.html sounds fine in beta and ToT on my linux box.

I reverted the two CLs locally on my mac.  No change in behavior. I still can't hear anything on the midi drum machine or the Pop demo.  None of the other CLs seems relevant (except maybe that src-internal roll, but that seems unlikely too).

Adding internals>media>audio for any insight they might have.

Hmm. This really seems like a Web Audio issue. Locally I've added a log inside if HandlePostRenderTask() to print out a message when the rendered buffer is non-silent.

1. Chrome Music Lab print out the message every render quantum.
2. SoundTrap POP demo did not print out any message.

This means the rendered buffer is actually silent. So this is not a bug from the audio infra. I am kind of guessing this is AudioParam-related.

I think I found the cause:
https://chromium-review.googlesource.com/c/chromium/src/+/1249275

The revert CL was not complete. My gut says the reverb module stays null forever once it is reset. The convolver usually works as a "master reverb" for the whole mix, so you get total silence because of "null" reverb processor.

Ignore #10.

andrew.macpherson@

71.0.3568.0 Canary - Some glitches at the beginning, and no audio.
71.0.3569.0 ToT as of 10/2 - Works fine.

I think you can try again with Canary > 3568. We are still figuring out why this is happening, but from what I found it is related to the convolver's render method.

Weirdly enough, now it can't be reproduced any more on ToT.

Something really strange that hongchan@ and I noticed.  Build ToT today on OSX.  Load the midi drum demo and start it. We hear the expected audio.  Start chrome canary and load the same page.  Press play.  No audio at all now.  Pause/stop the midi drum on canary.  After a couple of seconds, audio starts again from the ToT build.

Contrast this when doing the same thing with beta instead of canary.  Both will output audio.

This particular problem is probably not a webaudio problem since exactly the same code is being run.

Tested the midi drum and midi synth on Windows with ToT.  No problems.  No problems with canary either.

This seems to be Mac-specific.

I'm seeing the same behaviour as in #c12 here, in Canary it actually stops audio output from other programs running on the system (Firefox, Spotify, other Chrome versions) when the problem is occurring, which is really strange.

Also seeing the same as you with ToT though from last night, I had built ToT yesterday and was able to repro the problem there but as of last night's build it seems to be gone. Also only seeing it on Mac here, Windows Canary seems fine.

Just for reference here was a small script I was using to repro the problem, it causes massive glitching or no audio on Canary (71.0.3568.0) but sounds fine on ToT or stable: https://jsfiddle.net/4zL3wbna/11/

I'll check again once Canary > 3568 is out, thanks for looking into it rtoy@ and hongchan@!

I did another bisect to identify when the fix appeared and it gave this: https://chromium.googlesource.com/chromium/src/+log/59aed3764077ffd201c04490e81801d6a24ed9f2..ecd2d92d7b10e92cbf575862c9a9d3551062b26b

Comparing commits to the first bisect I found these:

https://chromium.googlesource.com/chromium/src/+/f369a29a01b3d8e8269afae32157f3e4e7ec7e3f
https://chromium.googlesource.com/chromium/src/+/a6519e88c07449783269f87535afea8e55effbdb

I did a manual revert of the second one on ToT and rebuilt and sure enough the problem reappears. So it looks like this was the cause and this ticket can be closed, thanks again for the help!

Wow!  Thanks for the bisect and narrowing down the problem with the fix.

+palmer: FYI: memory zeroing also causes strange things to happen with WebAudio.

Thanks Andrew!

Ray and I were so confused about why/how this can happen. Glad we found the culprit. So this is fixed by the second patch in #15. Correct?

Yeah, the optimization patch was a little over-eager. We're dialing it back now (https://chromium-review.googlesource.com/c/chromium/src/+/1256211) and I think/hope it shouldn't cause you any trouble. But if so, ping me.

hongchan@: Yes, from my testing this was fixed by the second patch. Thanks again!

per #18, #19, I am closing this issue.