Closed Bug 1056657 Opened 6 years ago Closed 1 year ago

WebAudio audio glitches on Firefox when queueing buffers


(Core :: Web Audio, defect, P3)

34 Branch





(Reporter: floooh, Unassigned)



(Keywords: parity-chrome)

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):

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:!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.
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.
Ever confirmed: true
Whiteboard: [Chrome-parity]
Component: Untriaged → Web Audio
OS: Mac OS X → All
Product: Firefox → Core
Depends on: 848954
Whiteboard: [Chrome-parity] → [parity-chrome]
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.
Priority: -- → P2
Rank: 25
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome]

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

Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.