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

171–179 of 179 posts

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

#171

Post by joshontheweb »

j_s wrote: post #165
joshontheweb wrote: post #145

I'm running a SaaS built on the back of the Web Audio + WebRTC apis. While it isn't perfect at all, it is still pretty impressive what progress has been made in the last few years allowing you to do all kinds of audio synthesis and processing right in the browser. It seems to me that it is a pretty general purpose api in intent. The approach seems to be to do the easy low hanging fruit first and then get to the more…

"Record in Lossless WAV" as feature #2 made me smile. Success to you with your SaaS!

Thank you ;)

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

#172

Post by kruhft »

TheOtherHobbes wrote: post #150
Jasper_ wrote: post #84

Earlier quoted context omitted.

I propose a challenge then. I'll give you an arbitrary stream in the format of a .wav, and you send me code, in JavaScript, that uses an series of infinite OscillatorNodes that reproduces that stream completely accurately. I won't even make you write the code that generates the stream, I'll just require that one sample. If you can do it, I'll give you $1000 out of my own pocket.

If you're not sampling at an infinite sample rate, you don't need an infinite series of nodes. Given Nyquist, a non-infinite series of [non-trivial power of 2] nodes will do the job just fine. Audio FFT/iFFT processing typically uses 512 or 1024 bins, although sometimes you can get away with fewer. In practice, iFFT doesn't use discrete oscillators for resynthesis, because the whole point of iFFTs is to limit the amo…

Thank you.

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

#173

Post by kruhft »

Jasper_ wrote: post #161
TheOtherHobbes wrote: post #150

Earlier quoted context omitted.

If you're not sampling at an infinite sample rate, you don't need an infinite series of nodes. Given Nyquist, a non-infinite series of [non-trivial power of 2] nodes will do the job just fine. Audio FFT/iFFT processing typically uses 512 or 1024 bins, although sometimes you can get away with fewer. In practice, iFFT doesn't use discrete oscillators for resynthesis, because the whole point of iFFTs is to limit the amo…

I'm well aware of discrete fourier transforms, and that we're dealing with a ~20KHz bandlimited signal. My original "infinite series" reply was a joke poking at the ridiculous idea of using iFFT for sample playback that seemed to get interpreted as a serious response by kruhft.

I was talking about synthesis, which is what the oscillators of web audio are for. I figured that was obvious.

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

#174

Post by roca »

mov wrote: post #147
roca wrote: post #114

Here's my take on the history here: http://robert.ocallahan.org/2017/09/some-opinions-on-history... From the beginning it was obvious that JS sample processing was important, and I tried hard in the WG to make the Web Audio API to focus on that, but I failed.

Back there I followed a bit the discussion and your alternative spec, which was really interesting. If I remember it well, that will take lots of work and you were the only one working to get it implemented on FF. Are there any plans to get back to that? Maybe as an independent API for JS sample processing by workers only, in parallel with WA? Congratulations on your past efforts and thanks in advance for your answer…

Audio Worklets are the future of JS audio processing.

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

#175

Post by fzzzy »

EdSharkey wrote: post #83
fzzzy wrote: post #52

Mozilla had a competing api that just worked with sample buffers. Unfortunately it didn't win the standardization battle. https://wiki.mozilla.org/Audio_Data_API

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…

I think having a simple api in addition to the Web Audio API is a great idea. I have no idea what the chances of that happening are though.

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

#176

Post by jancsika »

kevingadd wrote: post #122
symstym wrote: post #77

Earlier quoted context omitted.

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.

For bonus points, prep work done for the eventual rollout of AudioWorklet in Chromium shipped a bug to release channel Chrome that breaks all uses of Web Audio. The bug wasn't caught in beta/canary channels because it only affects some user machines, and they can't revert the bug because of architectural dependencies. A basic way to summarize it is that AudioWorklet required the threading structure of Web Audio to ch…

> But it sucks, and the blame for this horrible situation lies largely with the people who designed WebAudio initially

Just skimming it a bit, it seems like they tried to make the same kind of "managed" framework for an audio graph that SVG spec does for vector graphics. And even if SVGs are janky the static image still succeeds in serving a purpose. But if you get dropouts or high latency in audio, there isn't much more it can be used for. (Aside from browser fingerprinting :)

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

#177

Post by sitkack »

j_s wrote: post #163
bsder wrote: post #39

Earlier quoted context omitted.

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…

This has been a known issue with Android since at least 2009 (~2,700 stars); work done to address this is starting to trickle out this year. https://issuetracker.google.com/issues/36908622 AAudio is a new C API. It is designed for high-performance audio applications that require low latency. It is currently in the Android O developer preview and not ready for production use. (Jun 2017)

There are not a lot of artists at Google.

Until this changes, the media apis will lag as G attempts to maintain parity with other orgs. Google makes product for Google devs and incidentally for the world to use.

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

#178

Post by sitkack »

EdSharkey wrote: post #83
fzzzy wrote: post #52

Mozilla had a competing api that just worked with sample buffers. Unfortunately it didn't win the standardization battle. https://wiki.mozilla.org/Audio_Data_API

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…

Same thing applies to WebGL on iOS. Until you get someone to leak a damning document ... but theory is sound.

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

#179

Post by mort96 »

roca wrote: post #131
mort96 wrote: post #128

Earlier quoted context omitted.

Some person working at Google didn't know or care about Android? It doesn't seem all too unlikely that while he personally didn't care, his corporate overlords told him to work within the constraints of Android.

Chris Rogers started implementing his API in 2009, about three years before Chrome for Android was first released. And do you seriously think in 2009 some corporate overlord said to Chris Rogers, "Android is going to be big, and so is Chrome for Android, but we've decided Android will have a crappy audio stack for several years, so you need to design around that"?

I didn't know it was in 2009. I don't think it would've been too unlikely if he started it in, say, 2014.
Post reply on HN