I should add that I tested this on the Samsung View

Not sure what the issue is here, will need some investigation. I wouldn't count on this to work well generally though. If you need this kind of repetition WebAudio is much better choice.

I'd guess something is causing audio callbacks to be irregular (possible OpenSLES with a simple buffer queue isn't great at this).

yassam: could you compare with other devices as well? And as is mentioned above, I would assume that WebAudio is a better choice for what you want to accomplish.

I only have a Samsung Galaxy S3 and it's stuck on Chrome 47 because I don't have enough space to update it. It sounds even worse on this phone, for what it's worth.

Thank you for providing more feedback. Assigning to requester "rsgavara@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

I have an alternative to this code now that uses the Web Audio API. There's still a timing glitch:

http://buildoneforme.com/metronome-webaudio/

Each "click" is still triggered via setTimeout(). It uses uses an AudioBufferSourceNode, instead of an audio element, to play the click.

I realise this isn't the only way of using WebAudio, that there are alternative ways of doing the same thing and avoid the timing glitch. But I'd have thought what I'm doing in this code should sound ok, and it doesn't.

If you want precise scheduling of your clicks, using setTimeout to trigger the clicks with WebAudio is not the right way. cwilso@ has a great article on precise scheduling:  http://www.html5rocks.com/en/tutorials/audio/scheduling/

Thank you, yes I realise using WebAudio to do scheduling is the ideal solution, but just wanted to point out how significant the timing problems are on Android.

Just to be clear, the problem is not latency with setTimeout: I log the discrepancy between the actual time of the setTimeout callback and the desired time, and it's of the order of 0-2 milliseconds, which is well within the error margin I need. The problem is that even when I play audio at the right time (in response to setTimeout), the actual time the sound is emitted is way off. It sounds fine on the desktop.

I'd guess this happens when the audio device on android has a minimum buffer size longer than the period of your metronome click. We will play then try to play and write min_buffer_size frames and then immediately pause. If the next play() comes before min_buffer_size elapses, the play will be delayed.

I don't think there's any way we can guarantee this can work short of always creating an OS level stream for each play() attempt -- which is generally not desirable due to resource load.

I think this is WontFix with the expectation that short repeated sounds will need to go through WebAudio to work on a regular basis.

Note that WebAudio on Android has a fairly large latency mostly because no tuning was done.  This is in addition to the fact that some Android devices don't support a low-latency API so it's even larger.

This is WAI given the large buffer size required for certain Android devices.