Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don’t know who the Web Audio API is designed for

blog.mecheye.net

Post reply on HN
Print view View original

111–120 of 179 posts

Re: I don’t know who the Web Audio API is designed for

#111

Post by fenomas »

symstym wrote: post #103
fenomas wrote: post #98

Earlier quoted context omitted.

I tend to think of the Web Audio API as the answer to the question: "how much of an audio API can you have if you stipulate that all user-specified code must run in the UI thread?". Within that constraint I don't think it's a terrible API, but it's a big constraint and naturally raw access would be far preferable.

Yes.. after I wrote my comment I was feeling a bit bad for sounding like I was just trashing the API. In a world where JS is slow and there is no worker thread machinery, yet you need low latency and flexible processing, the design makes more sense. That being said, the AudioParam "automation" methods still make me want to cry.

Yeah, AudioParam's refusal to interpolate anything makes it really hairy to work with.

Comments on the spec suggest that there was something really complicated about the "cancelAndHold" method (which I guess is still in NYI limbo), but I can't for the life of me figure out what it was.

Re: I don’t know who the Web Audio API is designed for

#112

Post by wpietri »

_pgon wrote: post #31
Jasper_ wrote: post #26

Earlier 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…

> It's not "serious business" but this is the browser after all.

This answer would have made sense to me circa 2003, but I cannot fathom it today. The web started as "let's put academic papers online". It moved to "let's put magazines online" with some modest interactivity via forms.

But we've spent the last 10 or 15 years turning the web into a "you can do anything" platform. There's been huge progress in interactivity and visuals. There's no a priori reason audio should lag so far behind.

Re: I don’t know who the Web Audio API is designed for

#113

Post by arc_of_descent »

The Web Audio API is designed for web developers who would want to integrate sound into their web apps. Notifications, etc.

That pre-browser era where we would have sounds for everything. Minimize window, user logged in, logged out, all that crap.

Also the API has good support for visual. Spectrum analysis. This is pretty good for an education course to offer for beginners on sound processing.

I wouldn't use it for anything serious like a DAW.

Re: I don’t know who the Web Audio API is designed for

#115

Post by roca »

andrewguenther wrote: post #96
EdSharkey wrote: post #83

Earlier quoted context omitted.

I always thought some browser vendors who own mobile app stores wouldn't appreciate gamers having access to a distribution channel for great games on their platform that they didn't control. You can't have great games without great sound, so their mucking up the Sound API would be a nice way to stall the emergence. It's a conspiracy theory, I know. Reality is probably far more boring and depressing. :/ Like the blog…

My theory is that Google used it's influence to hinder the API so they could work around the problems with Android's audio stack. They pushed for an API they knew they could get to work on Chrome for Android, rather than fixing Android (which is supposedly improved in 8.0).

I doubt that theory. Chris Rogers @ Google drove the Web Audio API design, and he was recently ex Apple's Core Audio team, and probably neither knew nor cared about Android. More history: http://robert.ocallahan.org/2017/09/some-opinions-on-history...

Re: I don’t know who the Web Audio API is designed for

#116

Post by roca »

pcwalton wrote: post #72
dmitriid wrote: post #14

One word: w3c. I've said it before, I'll say it again: it exists in a vacuum, and is run by people who have never done any significant work on the web, with titles like "Senior Specifications Specialist". Huge chunks of their work is hugely theoretical (note: not academical, just theoretical) and have no bearing on the real world.

The Web Audio API was the work of the Chrome team, not the W3C in isolation. I'm right there with you as far as W3C criticism is concerned, but they don't deserve the blame in this case.

It was really the work of Chris Rogers. If more core Chrome people had been involved, I suspect things would have worked out better.

Re: I don’t know who the Web Audio API is designed for

#117

Post by code_duck »

bsder wrote: post #39
symstym wrote: post #18

I'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…

The API is frustrating because it is meant to hide the fact that Android audio sucks giant hairy donkey balls. If you give Web developers access to raw samples, they are going to expect it to work. When it doesn't on Chrome on Android, lots of people are going to start complaining and filing bugs. So, instead of fixing the audio path, they decided to bury its crappiness under a "higher-level" API which has fuzzier la…

Android audio is truly terrible for instrument apps. I don't understand how it suffices for things like games. I also don't understand why people even bother to make things like pianos and drum set… The latency is so extreme and inconsistent that even on recent phones they are useless. In contrast, iOS has had excellently playable instruments at least as far back as the iPod Touch 4.

Re: I don’t know who the Web Audio API is designed for

#118

Post by baybal2 »

bsder wrote: post #39
symstym wrote: post #18

I'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…

The API is frustrating because it is meant to hide the fact that Android audio sucks giant hairy donkey balls. If you give Web developers access to raw samples, they are going to expect it to work. When it doesn't on Chrome on Android, lots of people are going to start complaining and filing bugs. So, instead of fixing the audio path, they decided to bury its crappiness under a "higher-level" API which has fuzzier la…

Aha, I had that eerie feeling that I saw those crappy patterns somewhere else. So, Android it was

Re: I don’t know who the Web Audio API is designed for

#119

Post by rl3 »

rl3 wrote: post #65

> It [WebGL] gives you raw access to the GPU ... Not to be semantic, but that's technically incorrect. Indeed, if WebGL were to be supplanted by a lower-level graphics API, that would make a lot of people happy.[0] As far as the author's thesis concerning the Web Audio API: I agree that it's a total piece of shit. [0] https://news.ycombinator.com/item?id=14930824

Not to be pedantic, rather.

I've come to suspect that my phone's autocorrect functionality, HN's two-hour edit window, and my own brain routinely conspire against me to paint a picture of total idiocy.

Re: I don’t know who the Web Audio API is designed for

#120

Post by kevingadd »

iainmerrick wrote: post #107
cromwellian wrote: post #80

Isn't Web Audio based off of MacOS'x Audio API? I think the whole point is that Javascript used to be slow, and using the CPU as a DSP to process samples prevents acceleration. Seems to me what is needed is like "audio shaders" equivalent to compute/pixel shaders, that you farm off to OpenAL-like API which can be compiled to run on native HW. Even if you grant emscripten produces reasonable code, it's still bloated,…

Isn't Web Audio based off of MacOS'x Audio API? I hadn't heard that, but some of the "processor node" stuff does sound familiar. What OS X also has, though, is proper low-level low-latency sound APIs. And that's why there are so many Mac (and iOS) music apps.

It is more or less based on OS X audio, yes. The author of the Web Audio spec previously was an architect on Core Audio at Apple. He basically moved over to Google, implemented his chosen subset of Core Audio in webkit, and shipped it prefixed. Then the evangelism group got big players like Rovio to ship apps that depended on the half-baked prefixed API so it was the de-facto standard for game SFX on the web.
Post reply on HN