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

51–60 of 179 posts

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

#51

Post by kowdermeister »

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?

You can access the reduction property and connect it a gain node of anouther source.

https://developer.mozilla.org/en-US/docs/Web/API/DynamicsCom...

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

#53

Post by Jasper_ »

derefr wrote: post #50

Question: 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.

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.

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

#54

Post by jancsika »

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.

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

#55

Post by Jasper_ »

kowdermeister wrote: post #51
Jasper_ wrote: post #30

Earlier quoted context omitted.

Where's the sidechain input?

You can access the reduction property and connect it a gain node of anouther source. https://developer.mozilla.org/en-US/docs/Web/API/DynamicsCom...

That's using the output of the compressor to drive another node. A sidechain compressor has two inputs.

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

#56

Post by TFortunato »

sdeep27 wrote: post #43
bsder wrote: post #36

Earlier quoted context omitted.

> 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.

I can't tell if your being pedantic because you agree with the parent, or because you missed their point entirely

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

#57

Post by derefr »

Jasper_ wrote: post #53
derefr wrote: post #50

Question: 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.

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?

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

#58

Post by romwell »

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…

Off-topic, but thanks for Cakewalk! I got started making music on Cakewalk 5, and it's been a ride ever since.

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

#59

Post by netule »

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…

Damn, I just played with the Plinth demo for an hour, lost total track of time. Great stuff.

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

#60

Post by jpernst »

Tanner wrote: post #9

This article focuses on emscripten examples and for good reason! The effort to resolve the differences between OpenAL and Web Audio has been on-going and exacerbated by Web Audio's API churn, deprecations and poor support. That said, this current pull request on emscripten is a fantastic step forward and I'm very excited to see it's completion: https://github.com/kripken/emscripten/pull/5367

I'm one of the authors of this PR, and yes, WebAudio's baffling lack of proper consecutive buffer queuing has been no small source of frustration. They seem to have put so much effort into adding effects nodes and other such things, but something as simple as scheduling one sound to play gaplessly after another can't be (easily) done. Requests for such support have been batted aside as unnecessary, which is funny considering where all the effort is going instead.

To do it properly would require just giving up on WebAudio's features completely and doing all the mixing in software via WebAssembly. Honestly though, if you're going to do that, you may as well just compile OpenAL-Soft with emscripten and use that, so I opted to just try to get the best out of WebAudio that I could. Hopefully it's good enough.

Post reply on HN