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

31–40 of 179 posts

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

#31

Post by _pgon »

Jasper_ wrote: post #26
_pgon wrote: post #22

Earlier quoted context omitted.

It's a higher level API and you're deliberately ignoring all of its higher level features and concentrating on the part that clearly is underdeveloped. Maybe you should use your imagination instead of putting a square peg in a round hole?

> 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 functionality, well, I'm sure the AudioWorkers will catch up eventually.

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

#32

Post by Jasper_ »

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

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.

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

#33

Post by graphememes »

Jasper_ wrote: post #30
kowdermeister wrote: post #28

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

Where's the sidechain input?

Just the BASICS. Like before we knew anything about Audio

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

#34

Post by whipoodle »

kowdermeister wrote: post #28

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

Still, the cross-browser thing seems quite bad.

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

#35

Post by bsder »

stupidcar wrote: post #12
revelation wrote: post #6

The major problem of this API is that they couldn't just copy something designed by people with actual knowledge, as in WebGL. So it was design by committee that does so much the application should handle but has so deficient core capabilities no application can rectify any of it.

Nope. Web Audio was designed almost entirely by a single person, Chris Rogers, an engineer with a long history of working on audio for Google, Apple and Macromedia[1]. Whatever Web Audio's problems, design-by-committee is not their cause. [1] https://www.linkedin.com/in/diagonal/

> Web Audio was designed almost entirely by a single person, Chris Rogers, an engineer with a long history of working on audio for Google, Apple and Macromedia[1].

Who at Apple beat him with a stick to get audio right? Can we get that person to design the audio API's for the Web and Android?

(Edit: I realized that this was an unfair comment born of my frustration with Audio APIs from Google.

The real issue driving this is that audio is still a dumpster fire on Android. So, if he gives web developers access to audio samples, everybody is going to expect it to work. And, on Android, it will fail miserably. So, better to isolate audio functions, give them "fuzzy" latency which you can bury in C code drivers, and hide the fact that audio on Android is a flaming pile of poo rather than piss off even more developers and get even more bugs filed against Android's shitty audio.)

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

#36

Post by bsder »

kowdermeister wrote: post #28

Stopped 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 multiple pieces--and I can't escape.

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

#37

Post by ssfrr »

Jasper_ wrote: post #16
kruhft wrote: post #5

Earlier quoted context omitted.

> However in the audio world we haven't seen a cross platform quasi-standard spec covering Mac, Linux and Windows. OpenAL: https://www.openal.org/

Don't let the name fool you. OpenAL is a closed-source library, much like Wwise or FMOD or PortAudio, that just implements playback. Bizarrely enough, it is also the only one of these APIs that uses a similar "play this buffer" approach and suffers from the same issues as Web Audio's memory management, just without a GC. The actual audio equivalent to OpenGL is OpenSL [0], which I don't think picked up any support fr…

PortAudio is MIT-licensed[0] and seems like a decent example of the primitives you need for audio.

Broadly low-level audio APIs are divided into 2 categories:

1. Callback-based - every time the underlying system has a new block of audio available and/or needs to be supplied with a new block, it calls your callback, which reads input data, does whatever processing you want, and writes output data

2. Stream-based - Inputs and Outputs are represented by streams. You can read from the input stream to record and write to the output stream to play back.

Both types of API can be used for low-latency audio, but you generally introduce a buffer of latency when you need to convert between them.

Portaudio lets applications choose which API they want to use.

[0]http://www.portaudio.com/license.html

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

#38

Post by kruhft »

Jasper_ wrote: post #27
kruhft wrote: post #24

Earlier quoted context omitted.

> Please use your imagination and try to imagine one of infinitely many other streams that I could make at runtime that are not easily made with the built-in toy oscillators. Somebody already did. Check out Fourier Theory. The oscillators (well actually just sin, the rest will give you some help as well) can be used to make any stream, technically.

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.

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

#39

Post by bsder »

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 latency and can be built with hacks in the audio driver stacks themselves.

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

#40

Post by metajack »

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…

I think there were alternative designs but either no one cared or people were determined to push WebAudio despite faults. An example alternative that was proposed is http://robert.ocallahan.org/2012/01/mediastreams-processing-...
Post reply on HN