Can't seem to add Andrew directly, so +WebAudio.

Exactly which Samsung phone?  If you can, run http://rtoy.github.io/webaudio-hacks/tests/osc.html and report back the sample rate and baseLatency value that is printed.

My guess:  this Samsung phone doesn't support the low-latency path and therefore has a huge buffer size.  A latency hint of 'playback' is way too small for this phone.

Hmm, I thought 'playback' always used the recommended buffer size?

I think playback means 10 ms.  I'm also guessing that Hangouts and other WebRTC things are working on this phone, so WebAudio is confused about something.

I've reproduced on Galaxy S7 edge, but my colleagues reported reproducing this on other Samsung devices as well.

The test page reports the following values:
48kHz sample rate
baseLatency 0.08016666 sec (3848 frames)

That's definitely wrong if true; playback needs to mean std::max(preferred_buffer_size, 20ms). 

Which is what it is: https://cs.chromium.org/chromium/src/content/renderer/media/renderer_webaudiodevice_impl.cc?type=cs&q=GetHighLatencyBufferSize&sq=package:chromium&l=62

So it seems something else might be wrong. Or WebAUdio doesn't like the returned size.

Err, sorry, I'm wrong it's passing in 0 for preferred_buffer_size, so that's definitely wrong. 

Thank you for providing more feedback. Adding requester "rtoy@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

dalecurtis@: thanks for checking.  We'll have to take a look.

tomer@:  Thanks for the info. I don't understand why these high end Samsung phones don't seem to support the low-latency audio mode in Android.

I can reproduce the glitching audio from the URL above on a Samsung Galaxy S7 here as well, though I only see the latencyHint reported in #6 for 'interactive' and 'balanced', not 'playback'. Visiting this fiddle:

https://jsfiddle.net/shcguhmL/1/

Gives a buffer size of 3848 for both 'interactive' and 'balanced' and gives 1024 for 'playback'. It sounds like rtoy@'s comment in #3 may be the issue, since the 'playback' buffer size on this device actually ends up being lower than 'interactive'.

It sounds like the solution may just be to pass the hardware_buffer_size (which I guess is 3848) instead of 0 as the preferred_buffer_size to GetHighLatencyBufferSize() in the line pointed out by dalecurtis@ above:

https://cs.chromium.org/chromium/src/content/renderer/media/renderer_webaudiodevice_impl.cc?type=cs&q=GetHighLatencyBufferSize&sq=package:chromium&l=62

I can set up a tiny CL to do this if this makes sense.

If I'm reading the code correctly, for non-windows devices, the return value is only a function of the sample rate:
https://cs.chromium.org/chromium/src/media/base/audio_latency.cc?type=cs&sq=package:chromium&l=40

Since you invoke AudioLatency::GetHighLatencyBufferSize() with a preferred_buffer_size of 0, the return value is only a function of the sample rate.
For a sample rate of 48000, 20 ms would be 960 samples, rounded up to the next power of 2, it would be 1024 samples (regardless of hardware capabilities).
This is quite a small buffer size, see https://cs.chromium.org/chromium/src/media/base/audio_latency.cc?type=cs&sq=package:chromium&l=126

Maybe you should re-consider the 20 ms const?
It might be too small...

Yes, the correct solution is to not pass 0 here; we only allow the zero pass for one specific case; probably we should remove it from the API and have a secondary method for that one special case in AudioRendererImpl.

assign to rtoy and remove from unconfirmed bucket.

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

commit a6eff37d1caa458167193591357a5b5ce26a27c0
Author: Andrew MacPherson <andrew.macpherson@soundtrap.com>
Date: Wed Aug 02 08:19:57 2017

Fix for AudioContext 'playback' latency on Android

Creating an AudioContext with a latencyHint of 'playback' on some
Android devices could cause glitching as the context was created
with an audio buffer size less than the hardware buffer size.

BUG= 745960 

Change-Id: I1db4efe934f427c878ad30bfb3507c535383b82d
Reviewed-on: https://chromium-review.googlesource.com/579068
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Raymond Toy <rtoy@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Andrew MacPherson <andrew.macpherson@soundtrap.com>
Cr-Commit-Position: refs/heads/master@{#491308}
[modify] https://crrev.com/a6eff37d1caa458167193591357a5b5ce26a27c0/content/renderer/media/renderer_webaudiodevice_impl.cc
[modify] https://crrev.com/a6eff37d1caa458167193591357a5b5ce26a27c0/content/renderer/media/renderer_webaudiodevice_impl_unittest.cc
[modify] https://crrev.com/a6eff37d1caa458167193591357a5b5ce26a27c0/content/shell/renderer/layout_test/layout_test_content_renderer_client.cc

Fix has landed.

tomer@, can you try a canary build of Chrome with your device and check if everything is working.

Fix looks (sounds) good, thanks!

Thanks for testing!

The NextAction date has arrived: 2017-08-23