Curiously, reading through Web Audio API bug tracker find items such as https://github.com/WebAudio/web-audio-api/issues/1305 and https://github.com/WebAudio/web-audio-api/issues/938, that echo the point from the article quite well. Oh dear..
I don’t know who the Web Audio API is designed for
41–50 of 179 posts
Re: I don’t know who the Web Audio API is designed for
#42Earlier quoted context omitted.
> It's a higher level API As the title of the post asks: "I don't know who the Web Audio API is designed for". The high-level nodes are not featureful enough for professional audio production, and too slow and underspecified for game engines like FMOD / Wwise. The low-level bits fall somewhere between impractical, deprecated, and useless. Who is it designed for?
I think you're missing the point entirely. It's like a modular synthesiser. It's not "serious business" but this is the browser after all. Plug a few oscillators into each other and you have an FM synth. Feed delays into each other, etc, etc. You can do that in a few lines of code with no dependencies. To me, that's a huge potential audience. If you want a array of samples and depend on dozens of JS libs for function…
The ability to build primitive synths in a few lines of code (w/o library dependencies) is fine and well, but should not have been a priority for becoming a web standard. What's desperately needed is a well-designed low-level API. That could have been done years ago, and then if there was still sufficient demand for built-in nodes, those could have been added later.
As far as potential audience, in the time I've spent lurking in the Web Audio community, it seems like developers fall into one of two camps: 1) building toy projects for their own edification/learning, and happy to have the Web Audio API 2) trying to build a serious product (DAW, game, whatever) and super frustrated with the API. It seems pretty clear to me that end-users would be much better off if camp 2 had a good low-level API to work with.. camp 1 is not making much that gets used by end-users.
> It's not "serious business" but this is the browser after all.
Modern JS performance is actually quite good, and WebAssembly is only going to make it better. I think you underestimate the potential of audio processing in the browser.
> It's like a modular synthesiser.
I own hardware modular synths, and I built a proof-of-concept modular synth environment using the Web Audio API (https://github.com/rsimmons/plinth). The API makes it hard to build even simple things like well-behaved envelope generators or pitch quantizers. So even if you viewed the API as a sort of code-level modular synth environment, it's pretty unsuited to anything beyond trivial use cases.
The browser-based experimental/modular audio stuff that has any traction (e.g. https://github.com/charlieroberts) doesn't use the built-in nodes for these reasons.
Re: I don’t know who the Web Audio API is designed for
#43Stopped reading at: "Something like the DynamicsCompressorNode is practically a joke: basic features from a real compressor are basically missing, and the behavior that is there is underspecified such that I can’t even trust it to sound correct between browsers. " Then if you look into it: dictionary DynamicsCompressorOptions : AudioNodeOptions { float attack = 0.003; float knee = 30; float ratio = 12; float release…
> Which are indeed the basics that you need and totally enough for most use cases. However, I can take your "simple" compressor and swap it out of my audio chain for a more complex one if I need to. I can't do that for the Web Audio API. That's really what everybody is complaining about. The problem is that if your use case only covers 95% and I use 10 pieces, I am practically guaranteed to have a mismatch for multip…
If you have 95% coverage, and you have 10 separate random pieces, you actually have a 40% chance of failure.
Re: I don’t know who the Web Audio API is designed for
#44Earlier quoted context omitted.
> It's a higher level API As the title of the post asks: "I don't know who the Web Audio API is designed for". The high-level nodes are not featureful enough for professional audio production, and too slow and underspecified for game engines like FMOD / Wwise. The low-level bits fall somewhere between impractical, deprecated, and useless. Who is it designed for?
I think you're missing the point entirely. It's like a modular synthesiser. It's not "serious business" but this is the browser after all. Plug a few oscillators into each other and you have an FM synth. Feed delays into each other, etc, etc. You can do that in a few lines of code with no dependencies. To me, that's a huge potential audience. If you want a array of samples and depend on dozens of JS libs for function…
I guess we're all in agreement that it's a toy.
Re: I don’t know who the Web Audio API is designed for
#45I've spent quite a lot of time working with the Web Audio API, and I strongly agree with the author. I got pretty deep into building a modular synthesis environment using it ( https://github.com/rsimmons/plinth ) before deciding that working within the constraints of the built-in nodes was ultimately futile. Even building a well-behaved envelope generator (e.g. that handles retriggering correctly) is extremely tricky…
> I strongly agree with the author.
I will second this. I wanted to make a live streaming playback feature using the API so I could remotely monitor an audio matrix/routing system that I have in the office.
The API has _zero_ provision for streaming MP3. You either load and playback a complete MP3 file or you get corrupted playback because the API simply won't maintain state between decoding calls.
What I ended up having to do was write a port of libMAD to JavaScript and then use that to produce a PCM stream, which I _could_ then convert into an AudioBuffer, attach a timer, and then send into the audio API for correct playback.
Which is an insane amount of work for a gaping oversight in a common use-case of the API, a simple flag in the browsers native decoder would've sufficed.
Re: I don’t know who the Web Audio API is designed for
#46Earlier quoted context omitted.
Unfortunately, you need an infinite number of them to construct any signal, and I think my computer would run out of memory before that :)
Use a square wave.
Ah yes, just run a square wave at twice the range of human hearing, then use a combination of filters to extract the desired ranges. Unfortunately you'd also need an infinite arrangement of filters.
Re: I don’t know who the Web Audio API is designed for
#47Kinda tagential to the thread, but what's the best book for an introduction to audio programming for an experienced, language agnostic coder (java, c, c++, obj-c, etc)?
Re: I don’t know who the Web Audio API is designed for
#48>> Can the ridiculous overeagerness of Web Audio be reversed? Can we bring back a simple “play audio” API To be frank, graphics world had some type of standard (OpenGL) long time ago, next to DirectX. So WebGL had a good example. However in the audio world we haven't seen a cross platform quasi-standard spec covering Mac, Linux and Windows. So IMHO, non-web audio lacks also common standards for mixing, sound engineer…
Whether the API could be used to play MOD files is a good litmus test of its suitability for a variety of purposes. Covers repeatedly playing samples at differing volumes and pitches, simultaneously. I'd rather have a comprehensive API that someone can dumb down than one that's so crippled as to be unusable beyond very basic functionality.
A FastTracker 2 player was discussed on HN quite some time ago (spoiler: uses ScriptProcessorNode): https://news.ycombinator.com/item?id=10538791
Re: I don’t know who the Web Audio API is designed for
#49I disagree with a lot of the assertions in this blog. You have to suspend some of your expectations since this is all .js. you can't have a js loop feeding single samples to a buffer. Js isn't deterministic to that level of granularity, but overall it's fast enough to generate procedural audio in chunks if you manage the timing. If you check out some of the three.js 3d audio demos you can see some pretty cool stuff being done with all those crazy nodes the auThor is decrying. He'll I wrote a tron game and did the audio using audio node chains and managed to get something really close to the real tron cycle sounds, without resorting to sample level tweaking.. and with > 16 bikes emitting procedural audio.. I think more focus on the strengths than weaknesses is in order.. and if you really want to peg your cpu.. you can still use emscripten/webasm or similar to generate buffers, if that's your thing..
Re: I don’t know who the Web Audio API is designed for
#50Question: is the "point" of Web Audio to expose the native hardware-accelerated functionality of the underlying audio controller, through a combination of the OS audio driver + shims? Or is it more an attempt to implement everything in userspace, in a way equivalent to any random C++ DSP graph library? I've always thought it was the former.