Live data from Hacker News

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

blog.mecheye.net

61–70 of 179 posts

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

#61
post #4

How to play a sine wave: const audioContext = new AudioContext(); const osc = audioContext.createOscillator(); osc.frequency.value = 440; osc.connect(audioContext.destination); osc.start(); "BufferSourceNode" is intended to play back samples like a sampler would. The method the author proposes of creating buffers one after the other is a bizarre solution.

> The method the author proposes of creating buffers one after the other is a bizarre solution.

I used the same solution when I tried to perform realtime audio streaming from a daemon on an embedded device to a browser (which is probably even a more realistic use-case for a browser audio API than generatic sine waves). I basically stumbled over the same issues than the author: A deprecated ScriptProcessorNode and high-level APIs which don't help me (like the oscillator one).

In the end I opted for a very similar solution as the author: Whenenver I got enough samples through websocket (I encoded them simply as raw 16bit samples there) I created a BufferSource, copied all samples in there (with conversion to floating point), and enqueued the buffer for playback at the position where the last buffer finished.

I really didn't expect that to work well due to all the overhead of creating and copying buffers and due to the uncertainity whether the browser will switch between 2 buffers without missing samples. But surprisingly it worked and did the job. I included a buffering of 200ms, which means I only started playback 200ms to be able to receive more data in the background and have a little bit more time to append further buffers. I experimented a little bit with that number but can't remember how deep the lower limit was before getting dropouts regurarly. It definitely wasn't usable for low-latency playback.

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

#62

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…

The LA2A is as basic as they come. And it's more used for its character and coloring than for its flexibility.

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

#63

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…

Whoa, you made CakewalK! Thank you so much! Cakewalk inspired a lifelong love of music creation for me. You rock!

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

#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 - just build a cross platform interface using Electron App and use the underlying WebAudio to fire off MIDI messages.

Unfortunately, at the time of developing the project, WebAudio's MIDI SYSEX spec was still too fluid or not completely defined, so I had trouble sending/reading SYSEX messages via the API, and thus shelved the project for another day.

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

#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

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

#66
post #59
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.

Thanks! After a certain point it felt like a dead end to me, so I dropped it in favor of exploring something more along the lines of a JS-based Max/MSP. But it is surprising how much fun can be had with the small number of modules available in Plinth.

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

#67
post #55

Earlier quoted context omitted.

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.

I know what sidechain compression is, yes, you need to code a little bit more :)

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

#68
post #57
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?

H.264 is a video codec.

If you mean AAC or MP3, which are usually used in the audio track along side H.264 in an MP4 or MP2-TS container, nobody outside of low power/embedded bothers to decode the audio codec in hardware, it's just not worth it.

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

#69

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/

Yes, in fact the problem here is that Rogers barely considered spec input from outside (and others at Google have continued this behavior). A committee's design would've resulted in a better outcome in this case.

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

#70

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.
Post reply on HN