HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
WebAudio
web-audio-api
Bikeshed2014–2021
WebAudio / web-audio-api

web-audio-api

The Web Audio API v1.1, developed by the W3C Audio WG

Web DevelopmentCreative & Media
Explore on GitHubRead Hacker News discussions
9Distinct people
11Mentions
0Explicit recommenders
1.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Web Audio API v1.1, developed by the W3C Audio WG

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2014-06-18 01:32:14 UTC to 2021-04-17 17:37:42 UTC.

01232014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC202
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC303
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

11 sources
gruez·Nov 21, 2020
>But that's referring to privacy.resistFingerprinting (RFP), not adding randomness having a randomized fingerprint is a fingerprint value in and of itself. That may leak more entropy bits if you have a fairly common hardware configuration Also, regarding webaudio fingerprinting, afaik it's not a real threat. https://github.com/WebAudio/web-audio-api/pull/2224#discussi... https://github.com/w3cping/tracking-issues/issues/53#issueco... >As I said, I can't use RFP, it breaks too many sites. Weird. I only know a few sites that break with RFP on, and I don't use them frequently.
In Cover Your Tracks
TheRealPomax·Nov 11, 2020
Fun fact, I ran into the esampling problem myself back in April when I posted https://github.com/WebAudio/web-audio-api/issues/30, V2 of the spec will allow this natively, but it also not seemingly making any headway towards initial release so who knows when it'll land... What you can do though is look at the first few bytes of an .mp3 file (since it's a file drop/file load) to just directly read the sample rate from the MP3 block header[1], where you directly check the value encoded by [data[19], data[20]]: if it's [0,0] that means it's 44100, [0,1] means it's 48000, [1,0] means it's 32000 and that's it. There are no other sample rates allowed for MP3. [1] http://mpgedit.org/mpgedit/mpeg_format/MP3Format.html for the full block format)
In A hidden gem in sound symmetry
aeroheim·Sep 25, 2020
hi HN! I've been working in the browser audio domain recently and noticed to my surprise that WebAudio has no way to decode audio files efficiently. WebAudio has no support for partial decoding and can only decode entire audio files upfront which results in huge CPU and memory usage. For example, decoding a typical stereo 44.1 KHz 1-hour long audio file (e.g a podcast) into uncompressed floating point samples would consume (3600s * 44100Hz * 4 bytes * 2 channels) = ~1.27 GB of memory. Nice Obviously this isn't acceptable so I ended up creating this library to work around this issue. I ported FFmpeg over to WASM using Emscripten (a painful process) and then implemented an audio decoder with support for partial decoding. I hope this library can help anyone else with the same issue or at least serve as an additional reference for those look
Read the rest
ing to roll their own WASM-based workarounds. Thanks for taking a look! P.S: extra info/ranting about WebAudio below for those interested Others have already pointed out this glaring issue in the WebAudio API: https://github.com/WebAudio/web-audio-api/issues/1305 But it's sad to see that so many libraries/applications out there still rely on it such as: https://github.com/bbc/waveform-data.js https://github.com/katspaugh/wavesurfer.js Thankfully this issue should hopefully be addressed whenever WebCodecs is standardized and implemented: https://github.com/WICG/web-codecs/issues/28 But until then it's quite disappointing that developers have to go as far as rolling their own WASM-based solution just to work around the WebAudio API. I've heard unpleasant things about WebAudio and came in with zero expectations and yet was still disappointed. ¯\_(ツ)_/¯
In Show HN: Decode audio files in the browser without insane memory usage
bartread·Sep 14, 2017
And I'll third it. The MP3 issues don't end there, which is something the article touches on obliquely: you can't reuse many of the important constructs you might want to. Here's my use case. I have a couple of games (https://arcade.ly/games/starcastle, https://arcade.ly/games/asteroids), each of which has three pieces of music: title screen, in game, and game over. If you play the game a couple of times you're going to hear the title screen audio probably once, in game twice or more (because it loops from the beginning after every playthrough), and game over twice. To put it simply: I need to play the same MP3s multiple times each. To play an MP3 you have to decode it, which is an expensive operation. Firstly it takes time to decode - enough time that the user will notice the lag even on a fast machine. However the main problem is the am
Read the rest
ount of memory use: decoding takes you from a couple of MB of compressed MP3 to potentially hundreds of MB of uncompressed audio. The problem worsens for multiple tracks. I discovered the memory issues via Chrome Task Manager, when I noticed my page using hundreds of MB of native memory, and traced this usage back to the music. You can often get away with this when running on a desktop browser, but not so much on mobile. You can mitigate the memory issue to some extent by dropping the sample rate of your uncompressed PCM audio to 22.05KHz, which obviously halves its uncompressed size. Quality starts to suffer too much for music if you go much below this though. (Note here that I'm talking about the uncompressed sample rate, and NOT the MP3 bitrate. A 44.1KHz MP3 encoded at 64Kbps and one encoded at 128Kbps will decompress to the same size, although the 64Kbps version will obviously sound worse because more information will have been lost.) But the inability to reuse a source buffer, which holds compressed audio, is absolutely aggravating, and something I've posted at length about here: https://github.com/WebAudio/web-audio-api/issues/1175. The reason you might want to do this is because it means you're only using as much memory as the compressed audio takes up and (hopefully) the rest will have been freed by the browser's runtime (no guarantees, obviously). The downside of this approach is that you can't start a piece of music at a defined instant, which is extremely frustrating when you might want to synchronise it with events happening on screen. Also, due to the re-decoding every time, and the asynchronous nature of such, I've now introduced a weird bug where it's possible to end up with both title and in game music playing at the same time if the user starts the game before decoding the title music is complete. It's fixable (although I haven't had time yet), but it's just one more irritation with a poorly designed API. I'm actually thinking of going back to using the good old HTML5 AUDIO element just for playing music, since it seems a bit more reliable, but I need to do some experimentation to see what the memory impact is. I also had issues with AUDIO misbehaving quite badly in Firefox with multiple sounds playing simultaneously. Sound effects are less of an issue because they're obviously quite short and therefore don't take an excessive amount of memory even when uncompressed, so I can at least keep buffer sources around for them. Nonetheless the API's excessive complexity shows through even here: why is it such a drama just to play a sound? Why do I need to create and connect a bunch of objects together just to play a single sound at a given volume? Ridiculous. Asinine.
In I don’t know who the Web Audio API is designed for
padenot·Jun 15, 2016
An `AudioContext` (which is the object that lets you do non-trivial audio in the browser) does most of its work on a special, high priority thread, off an audio callback. Having `AudioContext` in a worker does not get you a lot. It's planned, but not prioritized very high. What happens when you're calling methods in JavaScript on an `AudioContext` is that we simply validate the input and queue messages to the audio thread, so this is effectively exactly what the article is talking about. We use some locking, but we've carefully wrote the code so that it's not really an issue. We lock just to swap two pointers in a message queue. This could certainly use atomics, but we have more important things to do first. That said, the interesting thing developers need and want is `AudioWorklets` [0], and that's what we at the W3C Audio WG is working
Read the rest
on more or less full-time, these days. It used to be called `AudioWorker`, but got renamed for a lot of reasons [1]. [0]: https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-... [1]: https://github.com/WebAudio/web-audio-api/issues/532
In Four common mistakes in audio development
cocoggu·Mar 3, 2016
Hey! I'm head of audio and MIDI at Flat. In fact, latency and audio quality (because of file sizes for sampling and because of available resources for synthesis) are two big limitations in a browser. We have big expectations about the upcoming Audio Workers ( https://github.com/WebAudio/web-audio-api/issues/113 ) to release advanced synthesizer. Also, we want to enjoy the capabilities of the MIDI output features, in order to route MIDI signals to Virtual Instruments on the computer (through virtual MIDI ports)
In Show HN: Flat – Music notation software: Web-based and Real-time collaboration
notthetup·Jun 18, 2014
"The WebAudio API does provide a ScriptProcessorNode for JS processing, but it appears to suffer from the problems I described." Yup. That is being worked on by W3C and the WebAudio committee as we speak. WebWorker based JS processing is something being considered. https://github.com/WebAudio/web-audio-api/issues/113 http://lists.w3.org/Archives/Public/public-audio/2013OctDec/... I am expecting this to be resolved in a few months. (hopefylly?) If the threading issues are resolved, then real time audio rendering doesn't take that much processing power and can be easily done in JS. Infact if there is nothing else contending for the EventLoop (like in this example of WavPot) the ScriptProcessorNode is able to meet the real-time guarantees pretty well, while still doing decent processing. Also going forward, with Technologies like SIMD.js and
Read the rest
asm.js more can be done within a single onprocess callback.
In Show HN: Wavepot – Digital audio workstation of the web

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.