Thanks for filing the issue!

Unable to reproduce the issue on reported chrome version 67.0.3396.79 using Mac 10.12.6 and Mac 10.13.1 with the below mentioned steps.
1. Launched Chrome
2. Navigated to https://www.musictheory.net/exercises/ear-note
3. Clicked On "Reference note".
Every time we click that bar we were able to hear the audio with out any issues. 

@Reporter: Could you please check the same in a new profile with out any apps & extensions and let us know if the issue still persists. Any further inputs from your end may help us.

It's not clear what is really supposed to happen.  I press the reference button a few times and hear the reference not and then I press one of the labeled buttons (for various notes). Sometimes the buttons will play and sometimes not.

Is that the actual issue?

Sorry, I should have been clearer in my original explanation!

The example page plays a note in the following situations:
1) When the Question or Reference button is pressed.
2) When you get a correct answer and the exercise moves on to the next question.

It sounds like both vamshi and rtoy experienced the correct behavior (which we are also seeing - we can't reproduce the issue from the reporter).

I've asked the original reporter to create a new profile without extensions.

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

As per comment#4 it s understood that the issue is not seen from your end too...Could you please confirm if we can close this issue even if Original reporter failed to reproduce it in a new profile. Hence Adding Needs-Feedback label.

Thanks!

I had the original reporter use a new profile without extensions and they experienced the same issue (although it sounds like it's highly random).

I also had them try using Shift-N to generate new questions (which creates a new audio buffer / buffer source) rapidly, but this didn't expedite the failure.

The failure can occur when a note is playing, and it sounds like the entire audio graph shuts down (the reporter reports a "click" and then silence until the page is reloaded, when this happens, our debug code still shows the AudioContext as running, no exceptions thrown, etc). From what I can tell, we aren't calling any WebAudio APIs when the failure occurs.

Is there a way to enable logging or access logging for the audio layers underneath WebAudio (I hesitate to have the user open Console.app and get bombarded with messages, but I can try to walk them through it if needed).

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

Unable to reproduce the issue on chrome reported version# 67.0.3396.79 and latest stable# 67.0.3396.99. Hence removing Needs-Bisect label. As per comment# 7 from the reporter(it sounds like it's highly random) and as this issue is not reproducible from TE end, hence requesting someone from the Blink>WebAudio team help in further debugging the issue.

Thanks!

As per comment #2 and #9, adding 'TE-NeedsTriageHelp' label as this issue is not repro at TE end and requesting someone from Blink>WebAudio team to look into the issue and help further.

Thanks..

We've had another report of this, this time from a user on Windows 10 running Chrome version 67.0.3396.79.

Please let us know if there is any additional logging we can collect from our users (or add to our code) that would help to diagnose this issue. Thanks!

Another report from a user on an Asus CP201PA Chromebook. We purchased the same device, but were unable to reproduce the issue.

We had the user launch in Guest Mode with a single tab set to the failing URL. Audio cut out in this configuration after 1-3 minutes and required the page to be reloaded. As far as we know, Guest Mode in Chrome OS should eliminate the possibility of extensions interfering with the page.

We are still trying to add logging to our code, but as mentioned above, we haven't seen any indication via the WebAudio APIs that a failure has occurred - the AudioContext appears to still be running.

recciadams@

Have you tried chrome://tracing to profile the app? See this doc for the instruction:
http://bit.ly/2MSQlvP

@hongchan - Thank you! I didn't know about chrome://tracing. This will be helpful in the future!

I can see how profiling would be useful for a situation where audio momentarily drops out due to a buffer underrun. When I say "audio cuts out" in this bug, I mean that audio stops playing entirely until the page is reloaded.

In any case, I tried profiling our app but didn't see anything abnormal. However, we are unable to reproduce this issue on our test devices.

It's completely possible that our app is at fault here. However, the timing of reports suggests a potential regression in Chrome 67. We didn't changed our code in May or June, the first report of this issue came in early June. I'm not sure what changed in WebAudio in 67 though. The de-zippering changes were in 66, I think?

> I mean that audio stops playing entirely until the page is reloaded.

In rare cases, I saw the huge amount of buffer source nodes are not getting collected correctly, so it spends a massive CPU cycle. It leads to a complete silence. This might be the case, but it is really hard to tell without the profiling.

> In any case, I tried profiling our app but didn't see anything abnormal. However, we are unable to reproduce this issue on our test devices.

That was my guess. Does CPU go to 100% before it goes silent? This is easy enough to check with TaskManager in Chrome.

> the first report of this issue came in early June. I'm not sure what changed in WebAudio in 67 though. The de-zippering changes were in 66, I think?

rtoy@ can provide more detail on de-zippering change.

Thanks!

In the rare cases of huge CPU / garbage collection, do you remember if the audio context remained silent for new buffer source nodes? I can see how a massive dropout could lead to complete silence, but I'd expect the audio context to recover if a new buffer source was connected 10 seconds later.

Sadly, the Asus CP201PA Chromebook user dropped/damaged their device yesterday and can't test until they get a new one. I'll have future reporters check the CPU usage.

I looked over the de-zippering changes, but didn't see anything abnormal. My C++ is a bit rusty, however!

Right now, my best guess is that this affects a small percentage of our users, but we are getting reports due to the size of our user base.

Mac triage: is there any action we can take here? This bug has been Needs-Feedback for > 30 days now.

Note: I haven't heard of any additional reports from our users. This issue was affecting more than just Mac users.

That said, I'd appreciate knowing if there's any additional actions I can take or logging that I can collect from users the next time this happens. Due to our large user base, we tend to occasionally hit weird WebAudio edge cases. 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