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

71–80 of 179 posts

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

#71

Post by Lazare »

Jasper_ wrote: post #32
_pgon wrote: post #31

Earlier quoted context omitted.

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…

So, the answer to "Who is the Web Audio API designed for", according to you, appears to be "people who want primitive FM synthesizers". Not game developers, not professional audio production people. It's... not an answer I was expecting, but I suppose it's valid.

Talk about damning with faint praise.

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

#72

Post by pcwalton »

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.

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

#73

Post by subwayclub »

greghendershott wrote: post #19

My first lesson in this was the Roland MPU-401 MIDI interface. It had a "smart mode" which accepted timestamped buffers. It was great... if you wanted a sequencer with exactly the features it supported, like say only 8 tracks. It was well-intentioned, because PCs of that era were slow. The MPU-401 also had a "dumb" a.k.a. "UART" mode. You had to do everything yourself... and therefore could do anything. It turned out…

IIRC games made pretty good use of MPU-401 intelligent mode to drive the MT-32 module. The first really elaborate game scoring work on the IBM platform came through the MT-32(Sierra picked it up and everyone else followed - it was a good target for composers but in practice most people heard the music on Adlib/SB), so I would consider it successful in that niche.

And on that note, what I think Web Audio tried to be was a drop-in kit for game engines. Getting the full functionality of Unreal into the browser motivated the requirement for audio processing. But the actual implementation was muddled from the start: basic audio playback remains challenging(try to stream a BGM loop instead of load+uncompress and discover to your woe that it's not going to loop gaplessly, even when the codec is designed to allow that.) and my hobby stab at an independent implementation ran out of gas when I tried to get their envelope model working. The spec has a lot of features but not enough detail, and my morale sank further when I looked at how Chrome did it(stateful pasta code). I got something half-working, put it aside and never came back.

OTOH I had also tried Mozilla's system. That was very simple, and I got a synth working in no time at all with decent performance and latency. Optimizing from that point would have been the way to do it, but something in browser vendor politics at that time led to it being dropped.

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

#74

Post by throwa34943way »

For reference : https://www.audiotool.com/app ( using Flash ).

You just can't do that with the same level of tightness of rhythm on low hardware with web techs today. Flash was bad yet Flash also opened up insane possibilities on the web when it comes to multimedia applications that just can't be matched with Webtechs. ASM.js might fill the gap, but i haven't seen any equivalent yet.

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

#75

Post by BHSPitMonkey »

pitaj wrote: post #70
cyberferret wrote: post #64

I worked on a (now abandoned) project a while back using Web Audio API, but it was NOT for Audio at all - in fact, it was to build a cross platform MIDI controller for a guitar effects controller. As someone mentioned elsewhere on this thread Android suffered from a crappy Audio/MIDI library. iOS's CoreMIDI was great, but not transportable outside of iOS/OSX. Web Audio API's MIDI control seemed a great way to go - ju…

I think I know what you mean, but in my mind, MIDI is very much Audio.

It's more about expressing events in time than audio necessarily... Sometimes it's used just to keep other devices in sync with a tempo, sometimes it's used to control lights, and -sometimes- it tells an actual audio synthesizer when to start and stop making noise.

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

#76

Post by throwa34943way »

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…

(https://github.com/rsimmons/plinth)

This demo doesn't keep a straight 120 BPM on my machine, it's incapable of holding the rhythm after 10 seconds of playback ( I tried the first patch on the left , Edge browser).

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

#77

Post by symstym »

jancsika wrote: post #54

Just from skimming the spec, the AudioWorklet interface looks very close to what is needed to build sensible, performant frameworks for audio profs and game designers. So the most important question is: why isn't this interface implemented in any browser yet? That a BufferSourceNode cannot be abused to generate precision oscillators isn't very enlightening.

It's been under development for a very long time in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=469639

I think there were some false starts where previous specs were written and then found to have issues.

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

#78

Post by symstym »

derefr wrote: post #57
Jasper_ wrote: post #53

Earlier quoted context omitted.

Most consumer-grade audio hardware really only does playback. We've been doing software audio since around the turn of the century. In Chrome's implementation, none of the mixing, DSP, etc. go through the hardware, and I'm more than certain that's the case for every other browser out there.

Audio controllers do at least do hardware-accelerated decoding of audio streams in e.g. H.264, though, yes? But my question was more like: is Web Audio a mess mostly because it's an attempt to expose the features of the twenty-odd different OS audio backends on Windows/Mac/Linux, where the odd inclusions and exclusions map to the things that all the OS audio backends happen to share that Chrome can then expose?

> is Web Audio a mess mostly because it's an attempt to expose the features of the twenty-odd different OS audio backends

That is a good guess, but no. The main features of the Web Audio API (built-in nodes, etc.) are not backed by any kind of OS-level backend, it's all implemented in software in the browser. The spec design was based on what someone thought were useful units of audio processing. It's not a wrapping/adaptation of some pre-existing functionality.

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

#79

Post by symstym »

throwa34943way wrote: post #76
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…

( https://github.com/rsimmons/plinth ) This demo doesn't keep a straight 120 BPM on my machine, it's incapable of holding the rhythm after 10 seconds of playback ( I tried the first patch on the left , Edge browser).

That's unfortunate. I don't have a machine running Edge to test it on. It uses less than 20% of the CPU in Chrome on my 2012 Macbook Air. It's possible that it's a problem with my code, but in general the Web Audio API does not have very good cross-browser support.

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

#80

Post by cromwellian »

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, and less efficient on mobile devices than leveraging OS level DSP capability.

Post reply on HN