• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • AudioWorklet Latency: Firefox vs Chrome

    May 6th, 2020
    audio, tech  [html]
    Reading the Firefox 76 Release Notes I noticed that it now supports AudioWorklet. I tested out my whistle-controlled bass synthesizer, and it felt much better than in Chrome, though still not as responsive as the native version. I decided to take some latency measurements.

    I connected the computer (2017 MacBook Pro running 10.14.6) to an external speaker and microphone, set the browser to run a simple AudioWorklet-based echo, and set my phone to record. I made a sharp tapping sound, and looked at the recording to see the delay from when the original sound is recorded to when the echo plays it back.

    I tested Chrome and Firefox. I would have liked to compare to Safari, since Apple has historically taken audio latency very seriously, but they haven't implemented the AudioWorklet spec yet. I also tested Reaper and PortAudio [1] for comparison.

    Here's what this [EDIT: initially, see update at the end where everything gets faster] looked like with Reaper, Firefox, and Chrome all set to echo:


    (mp3)

    I made twelve clicks in a row, and saw Reaper at 15ms, Firefox at 62ms, and Chrome at 124ms. I learned which echo was which by turning off each in turn.

    You would expect that latency would be completely consistent, because you can't change the length of the delay without getting ugly artifacts, but in Chrome it was not consistent. Earlier I made a much longer recording (mp3) and taking the two sections where you can clearly hear Chrome echos (mp3, mp3) I get 78ms, 78ms, 77ms, 94ms, 94ms, 93ms, 93ms, 93ms and then later 88ms, 88ms, 88ms, 88ms, 88ms, 93ms, 109ms, 109ms, 114ms, 114ms, 120ms, 147ms, 152ms, 152ms, 152ms, 152ms, 152ms, 152ms, 152ms, 152ms, 152ms, 163ms, 153ms, 153ms. Since one of the projects I'd like to do with browser audio requires completely consistent latency, I'm not sure it would work at all in Chrome.

    PortAudio compared very similarly to Firefox, about 3ms faster. I'm not sure what Reaper is doing to get much lower latency than PortAudio and Firefox? If I was going to look into this further my next step would be to log which system calls they're making and try to figure out what they're doing differently.

    Overall, I'm very impressed with Firefox's AudioWorklet implementation's performance, and I hope Firefox pushes Chrome to do better as well.

    (Disclosure: I work for Google, which makes Chrome. I don't work on the browser, though, and I'm speaking only for myself.)

    Update 2020-05-07: after I published this, Chrome folks told me that passing {latencyHint: 0} when starting the AudioContext would tell it to use a smaller buffer. I was surprised by this, because the spec says the default value for latencyHint is "interactive: Provide the lowest audio output latency possible without glitching." But it does help, across browsers.

    Then Björn on LW pointed me to the getUserMedia call and recommended setting echoCancellation: false. I looked at the other settings available there and additionally decided to turn off noiseSuppression and autoGainControl, and set latency to zero. (echo-demo-v4)

    With all of these together, latency was much better in both Chrome and Firefox. Here's a long recording (mp3) of Reaper vs Firefox vs Chrome. This time Reaper was consistently 11ms and Firefox 14, but Chrome was not consistent. I got latency as low as 19ms, but as high as 41ms. I took a longer recording with Chrome (mp3) where you can see the latency as low as 19ms (most of the recording, including, ex, 0:10) but as high as 30ms (ex: 1:37). I wonder whether Chrome might be trying to dynamically determine what level of latency it can manage without dropouts?

    I've updated my whistle-controlled bass synth to use these settings, and on my Mac it's now great in Firefox, and nearly as good in Chrome. Here it is in Firefox, though you'll either need headphones or speakers that can do a good job with bass:


    [1] I used paex_read_write_wire.c with FRAMES_PER_BUFFER set to 64 and suggestedLatency set to defaultLowInputLatency and defaultLowOutputLatency. I installed portaudio (brew install portaudio) and then ran gcc paex_read_write_wire.c -o paex_read_write_wire -lportaudio && ./paex_read_write_wire.

    Comment via: facebook, lesswrong, hacker news

    Recent posts on blogs I like:

    Children’s podcast recommendations

    I’ve emailed my list to enough friends that I should really just post it. Podcasts have been a big part of Lily’s life since around age 4. Before that, she spent a lot of her time demanding of any available adult, “READ. READ TO ME” (once she literally as…

    via The whole sky October 11, 2020

    Collections: Iron, How Did They Make It, Part IVa: Steel Yourself

    This week, we continue our four(and a half)-part (I, II, III, IVa, IVb) look at pre-modern iron and steel production. Last week, we looked at how a blacksmith reshapes our iron from a spongy mass called a bloom first into a more workable shape and then fi…

    via A Collection of Unmitigated Pedantry October 9, 2020

    High-Speed Rail and Cities

    When preparing various maps proposing high-speed rail in Germany, I was told that it looks nice but it overfocuses on the largest cities and not about connecting the entirety of the country. I’ve seen such criticism elsewhere, asserting that high-speed ra…

    via Pedestrian Observations October 8, 2020

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact