Requesting MTV team to check the issue as we don't have Bluetooth headphones here with us.

Thanks!! 

I duplicated this using a Nexus 9 with an external bluetooth speaker.  Except there's always output (unlike step 3).

When the internal speaker is used, the osc plays perfectly.  When bluetooth is connected the audio glitches, and we see lots of fifo underflows.  Don't understand why that would be.  A N9 should be easily capable of playing out a single oscillator without any CPU issues.

Bluetooth does something weird with the audio device thread, but I don't know what.

Also, playing a youtube video works fine with or without bluetooth and when dynamically connecting the speakers.

rtoy@ could you do trace recording? [https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs]

okla@ What things specifically do you want traced?

Something is wrong with accounts on my phone :(
Now attempt to reply via email:

Everything (per instructions) if performance permits. Otherwise - audio. Thanks!

Also, if you mean 'when to trace': both when it glitches (WebAudio) and
when it's not (YouTube) for comparison would be useful.

Sorry for the delay.  Here are the traces you asked for.

Oops.  Here are the traces.  The internal file is the internal speaker and there are no glitches.  The bluetooth one is connected to the external bluetooth speaker, and it glitches.

For both cases, I just pressed the start button and recorded the samples for a few seconds.

Deleted: trace_n9-m61-bluetooth-glitching.json 5.9 MB

trace_n9-m61-bluetooth-glitching.json 5.9 MB View Download

Deleted: trace_n9-m61-internal-no-glitch.json 9.0 MB

trace_n9-m61-internal-no-glitch.json 9.0 MB View Download

Hmm, OpenSL ES is doing some internal rebuffering when using bluetooth. It issues callbacks for either 100 - 150 ms at a time, rather than having periodic callbacks. Since WebAudio doesn't keep this amount of data buffered, it gets underruns. Seems like WebRTC would also have issues with this behavior. Is this stream behavior expected? Adding some people who know OpenSL ES.

(Side note: we probably shouldn't use 128 frame buffers for this stream, doesn't seem like there's a point to having such small buffers.)

Some general comments. There is no explicit device handling done based on OpenSL ES in Chrome (generic Android APIs are utilized). Most likely, the actual result will depend on device and exact model of the BT device. I would not recommend tuning of buffer sizes for BT in OpenSL ES unless it can be shown that it is a very common problem. It could be a timing issue where a certain BT headset needs more time to enable its SCO channel (not sure if Chrome supports the Advanced Audio Distribution Profile (A2DP)).

pierredewilde@: is the issue unique for a particular Bluetooth headphone? Does the BT headphone support a microphone as well or is is a pure headphone (speaker only)?

No, the problem is not unique for a particular Bluetooth headphone. I have tested it with several low to high-end Bluetooth headphones: always the same issue. This is specific to Chrome (including Chrome Beta and Chrome Canary) since it works correctly with other browsers (Firefox, Safari, Samsung Internet).

All tested Bluetooth headphones are configured for media audio only (call audio is disabled).

Rebuffering with bluetooth hedaset here looks like this (see attachment):
1) BT headset requests ~80/150 ms from OpenSL ES (which suggests it renders at ~120 ms)
2) OpenSL ES pulls 128 frame buffers from output stream
3) Output stream is open at 2048 fpb, and that's what it pulls from the renderer (and rebuffers to 128 requested by OpenSL ES) via AudioOutputDevice => AudioOutputDevice requests 2048 fpb from WebAudio.
4) WebAudio pulls the graph at 256 fpb and rebuffers to the requested 2048


WebAudio fills up the buffer on WebAudio rendering thread, and AudioOutputDevice does not wait for it to finish => it renders silence while WebAudio is busy pulling the graph and filing up the FIFO.

I believe the glitch is specific to Chrome because WebAudio renders on a separate thread, and because other browsers are probably more optimal in terms of rebuffering.

Why do we open AudioOutputDevice for WebAudio at 2048 fpb on Android?

Deleted: zoomin_bluetooth.png 132 KB

	zoomin_bluetooth.png 132 KB View Download

rtoy - could you check if YouTube playback has the same issues with a BT headset, and make a trace recording for it as well? Then we'll know if it's WebAudio-specific.

AudioSyncReader blocks when waiting for data from Youtube and similar, but not from WebAudio (in M61). I think the WebAudio threading model was reverted in M62 which should give WebAudio time to render the data and thus solve the issue.

That's what I don't understand about this. OP reported the same issue on:
Chrome 61.0.3163.98
Chrome Beta 62.0.3202.45
Chrome Canary 63.0.3234.0

63 does not use a separate thread for WebAudio unless you explicitly enable the experimental AudioWorklet feature and call worklet.addModule().


olka@ Which version did you use to get the tracing data in #18?

pierredewilde@ Can you try again with the latest Canary? (M64<)

tracing data in #18 is yours from #13, just zoomed in (you can see timestamps of the zoomed in interval at the very top)

sorry, correction to #22: *rtoy's from #13

To analyze what's going on in M63 we need traces from M63 :)

I'll get the M63 traces later today.

Does M62 refers to Chrome Beta 62.0.x and M64 to Chrome 64.0.x ?

If yes, there is indeed a small improvement starting with M62: https://googlechrome.github.io/samples/webaudio-suspend-resume/index.html pauses and resumes correctly when you switch to/from another tab.

However, if you refresh the page (and therefore create a new AudioContext), no sound in heard in Bluetooth headphone.

Here is the complete sequence I use to test this issue:

Phase 1: OK
- disable BlueTooth 
- open https://googlechrome.github.io/samples/webaudio-suspend-resume/index.html
- click Start button => audio is started and heard in speakers
- switch to another tab => audio is paused
- switch back to WebAudio suspend/resume Sample tab => audio is resumed
- click Stop Button => audio is stopped
- click Start Button => audio is restarted

Phase 2 (following Phase 1): OK in M62+ but glitches in M61
- enable BlueTooth => audio is heard in BlueTooth headphone
- switch to another tab => audio is paused
- switch back to WebAudio suspend/resume Sample tab => audio is resumed (glitches in M61 but OK in M62+)
- click Stop Button => audio is stopped
- click Start Button => audio is restarted (glitches in M61 but OK in M62+)

Phase 3 (following Phase 2): no sound after refresh
- audio is still heard in Bluetooth headphone
- click Stop Button => audio is stopped
- refresh WebAudio suspend/resume Sample tab => a new AudioContext() is created
- click Start Button => no sound is heard in Bluetooth headphone.

HTH,
Pierre

Here are the traces using Chrome 64 (64.0.3250.0) canary. In this case, both the internal speakers and the bluetooth speakers sound fine---no glitching at all.

Deleted: trace_n9-m64-bluetooth-no-glitch.json 5.5 MB

trace_n9-m64-bluetooth-no-glitch.json 5.5 MB View Download

Deleted: trace_n9-m64-internal-no-glitch.json 5.2 MB

trace_n9-m64-internal-no-glitch.json 5.2 MB View Download

There are 2 issues: 'glitches' and 'no sound after page refresh'. 

'glitches' issue has been solved in latest Chrome versions. Fine.

What about the 'no sound after page refresh' issue ? See Phase 3 in comment #26. Thanks.

Not sure what changed between 61 and 64, but with 64, I can start with internal speakers (bluetooth off), start the demo, switch to bluetooth speakers and audio is fine.  Probably because 61 runs webaudio in a separate thread, which got reverted in 62 to run in the same thread as previously done pre 61 (same thread as the audio device).

In both 61 and 64, context.baseLatency is 42.6 ms (2048 frames).  This means WebAudio is batching up audio to deliver 2048 frames at a time.

For a Nexus 9, I think the latency should be smaller, but a logic bug basically makes it use 2048.

olka@ Here's the trace for a YT video playing out the bluetooth speakers using Chrome 64 canary. No audio glitches.

Deleted: trace_n9-yt-bluetooth-no-glitch.json 19.8 MB

trace_n9-yt-bluetooth-no-glitch.json 19.8 MB Download

Using Chrome Canary (64.0.3253.0) on my Nexus 9, I cannot reproduce Phase 3 (c#26).

Can you test with Chrome canary?

Hum, phase 3 of comment #26 has been tested with Chrome Canary (64.0.3253.0) on Samsung Galaxy A5 2016. Same issue: no sound after refresh.

Sorry about that.  Then I don't know what's happening, since I can't reproduce with my Nexus 9.  Could you use remote debugging to see if the context after reloading is actually running?  Context state should be running, and currentTime should be progressing.  If that's the case, then it's outside the realm of webaudio; if the current time is progressing, webaudio is generating audio, which is getting dropped somewhere.

I tried again with a Nexus 9.  Followed all the steps in phases 1-3, except for switching tabs. After reloading the page, and pressing start, there's no output at all.

But the context's currentTime is advancing, so webaudio is producing data. I even tried creating a new oscillator in the dev console and connecting it the destination.  Nothing.  And the tab's audio output icon isn't displayed, so nothing the audio system doesn't see any non-zero output either.

I thought I was dreaming, but now I'm not the only one. Thank you for your perseverance.

In c#34, if you then disconnect the bluetooth speakers, audio plays from the internal speakers as expected.

So something about being connected to the bluetooth speakers while refreshing is causing trouble.

I can also confirm that if you connect the BT speakers first, start chrome with the repro case, pressing start works. (It takes a bit to switch from internal to BT speakers, but sound does eventually play from the speakers.)  Press stop. and then refresh.  Press start.  No audio.

This seems really odd.  And all the while, the audio context currentTime is progressing.

Some additional info.  I added a print to PushPullFIFO::Push that prints out the number of non-zero values in output_bus, which is the data that webaudio produces and sends out to the device.

I can confirm that when the bluetooth speaker is connected and there's no output from the speaker when there should be, the prints say there are non-zero values being output.

This appears not to be a WebAudio problem.

Assigning to dalecurtis for further triage.

Just a quick addition:
I am also able to reproduce this issue on a several devices and headphones. In all cases where there is no audio I can observe the currentTime not to be progressing and large baseLatency values.
One thing that persuades some devices (specifically some Samsung) to play audio is starting the audio context with the "playback" latencyHint. The reported baseLatency then oddly reduced by a factor ten and currentTime behaves as expected.

Yes, there's a known bug that on Android, the "interactive" latency value as reported in baseLatency is actually larger in many cases than "playback".  We're working on fixing that.

But the fact that currentTime is not progressing seems to be a different issue?  I have not been able to reproduce that; all of my testing shows that currentTime is progressing.  But I've only tested Nexus devices because that's all I currently have.

Can be that we are falling back to a fake audio stream for some reason?
rtoy@: did you manage to collect traces for #34?

olka@ Is there an easy way to tell if we're falling back?

I'll get the traces for #34 soon.

Not something I have bandwidth to look into for a while.

Fix this issue. This is a huge problem. I am using Cordova and Web Audio Api and if blue tooth is enabled and paired before the app launches all web audio is dead.  If I then disable BT all audio is still dead. However if app runs first then BT is enabled it all plays fine. I can even turn BT on and off. Pair and UnPair still plays back. It is the sequence that with BT cant find the stream or WeB Audio api cant find BT as its external destination.

Yep. This issue was reported 6 months ago, confirmed, then... just waiting
to be solved.

I wonder why developers should report issues if there are not processed by
the Chrome team.

Thanks,
Pierre

Whether you want to report issues or not is up to you.  But if they're not reported, they definitely won't get fixed.

This is a bit complicated bug because it touches several components, some outside of Chrome (Android).

Thanks for your feedback. I would have appreciated such feedback earlier
without a gentle rant ;)

Since no one else picked this up and manager perf is about over. I'll take this back and try and look into it next week.

Hmm, I'm not clear on exactly what the problem is here. Or I can't reproduce any issues. I've tried the following on a ToT build:

- Connect bluetooth, start test page, click play button - this fails on ToT w/o disabling the autoplay policy that launched in M66, but after doing that it plays correctly.
- Disconnecting bluetooth headphones falls back to speakers/jack and connecting bluetooth headphones usurps speakers/jack.

Sound plays fine throughout all of this. Can someone clarify exactly what's broken?

Notably I am testing on Android 8.1.0 + Nexus 5x w/ Sol Republic Shadow BT headphones.

I did also try tab switches and disconnecting / reconnecting during those tab switches; still no hashing sound.

=>rtoy since I'm not able to reproduce.

Dale, can you try this? (After disabling autoplay policy.)  Sorry for not getting back to you sooner.

1. Connect BT speaker/headphone
2. Start chrome
3. Visit page https://googlechrome.github.io/samples/webaudio-suspend-resume/index.html
4. Press start

I hear nothing.

5. Create a new tab.
6. go back to the test tab

I hear audio now.

It's not 100% consistent, but mostly works for me.

Nexus 9, Android 6, Chrome 66

Just tried again, N5X + 8.1.0 + 68, always plays on start.

(always ~= 20 tries)

Perhaps a difference between Android 6 and 8? And why isn't there a playing icon on tab?

Yeah possibly something fixed in later version of Android. You only get the media controls for <video> or <audio> elements.

I meant the speaker icon on the tab.  When I run the test on desktop, the speaker icon on the tab shows up, but not on android.

Retried with a pixel 2, android 8.1.0, chrome canary.  Sound is always heard.

Can the reporter try again with a later version of android?

Are you talking about the tab audio indicator? That's a desktop-only feature.

Yeah. I didn't know that's desktop-only.  I guess I don't do enough audio on android.

The NextAction date has arrived: 2018-06-01

No additional feedback after one month.

Closing (Wontfix: no repro anymore)

Please re-open or file a new issue if this is still occurring.