1056657 - WebAudio audio glitches on Firefox when queueing buffers

Status: RESOLVED WORKSFORME

(Core :: Web Audio, defect, P3)

Description

[Andre Weissflog]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36

Steps to reproduce:

Here's a small emscripten demo which uses emscripten's OpenAL wrapper to continuously fill 4kByte audio buffers with a static square wave, and queues them for continuous playback, and recycles buffers after they are played. On Chrome, this plays without any noticeable audio artefacts. On Firefox (tested on OSX and Windows) there are very noticeable glitches within the first second, and on Windows there are audio glitches when manipulating the window (resizing etc):

http://floooh.github.io/oryol-sticky-tests/SynthTest.html

The update loop runs at 60fps (triggered by requestAnimationFrame), the playback samplerate is 22kHz, the sample buffers contain 2048 16-bit samples, so one buffer is good for about 0.1 seconds (100ms), so there's enough room for the update loop running at 16ms to fetch new buffers without the queue running dry (every time this happens, a log message in the text field should show up that playback has been started, this should only happen once at startup, or when the update loop would run at less then 10fps.

Backlink to emscripten discussion thread: https://groups.google.com/forum/#!topic/emscripten-discuss/2j82ExusqL4







Actual results:

Firefox has initial very noticeable audio glitches, and later slight glitches and clicks (at least on Windows) which doesn't happen on Chrome.


Expected results:

Audio playback should be stable, just as in Chrome.

Comment 1

[Jukka Jylänki]

I can reproduce on Windows. In Firefox, the audio starts out bad, but stabilizes after 0.5s-1.0s seconds. After that, there are occasional glitches every 5-10s or so. In Chrome, audio does not exhibit artifacts.

Comment 2

[Paul Adenot (:padenot)]

We should look into why this still does not work. I think it's a clock issue, as in, we report the wrong clock on the main thread.

Comment 3

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 4

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 5

[Paul Adenot (:padenot)]

This now seems to work well. In addition, AudioWorklet will provide a robust way of doing this.