Live data from Hacker News

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

blog.mecheye.net

131–140 of 179 posts

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

#131
post #128
post #115

Earlier quoted context omitted.

I doubt that theory. Chris Rogers @ Google drove the Web Audio API design, and he was recently ex Apple's Core Audio team, and probably neither knew nor cared about Android. More history: http://robert.ocallahan.org/2017/09/some-opinions-on-history...

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"?

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

#132
post #129

I tried making a simple Morse code trainer using the Web Audio API, which seemed perfectly suited to the task, but I ran into two major problems: 1. Firefox always clicks when starting and stopping each tone. I think that's due to a longstanding Firefox bug and not the Web Audio API. I could mostly elminate the clicks by ramping the gain, but the threshold was different for each computer. 2. This was the deal-breaker…

Is that actually a bug? If you start a tone instantly without ramping the volume, the first sample should be relatively loud, which will click. It is reasonable to want and even expect a different behavior, but it might not be what is specced.

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

#133
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…

That... explains why Google was so keen to kill off the Audio Data API Mozilla proposed, I guess.

But Chrome for Android didn't come out until 2012 and Chris Rogers started the Web Audio work in 2009. I think someone would have had to have been exceptionally farsighted to think "Android's audio stack is going to suck for several years so we need to design around that now".

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

#134
post #130
post #129

I tried making a simple Morse code trainer using the Web Audio API, which seemed perfectly suited to the task, but I ran into two major problems: 1. Firefox always clicks when starting and stopping each tone. I think that's due to a longstanding Firefox bug and not the Web Audio API. I could mostly elminate the clicks by ramping the gain, but the threshold was different for each computer. 2. This was the deal-breaker…

> Firefox always clicks when starting and stopping each tone. I think that's due to a longstanding Firefox bug and not the Web Audio API. I could mostly elminate the clicks by ramping the gain, but the threshold was different for each computer. You sure it is not due to the sound files you are using not having a normalized start?

There were no sound files. I used an oscillator and changed the gain with `setTargetAtTime` to briefly fade in and out. That should prevent any clicking, but in Firefox it required an excessive amount of time.

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

#135
post #129

I tried making a simple Morse code trainer using the Web Audio API, which seemed perfectly suited to the task, but I ran into two major problems: 1. Firefox always clicks when starting and stopping each tone. I think that's due to a longstanding Firefox bug and not the Web Audio API. I could mostly elminate the clicks by ramping the gain, but the threshold was different for each computer. 2. This was the deal-breaker…

Is that actually a bug? If you start a tone instantly without ramping the volume, the first sample should be relatively loud, which will click. It is reasonable to want and even expect a different behavior, but it might not be what is specced.

Yes, to clarify, I was using `setTargetAtTime` to ramp the volume, but it was still clicking in Firefox without an extra hack. At the time I found a bug report that appeared to point to the cause (something related to internal audio buffers that Firefox uses), but I'm not finding it at the moment. It could have been fixed.

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

#136

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.

> work of the Chrome team

Indeed. Because people who do browser internals and never do any web development are a good fit to create APIs for web developers

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

#137
post #101

Earlier quoted context omitted.

> The API has _zero_ provision for streaming MP3. Did you look into Media Source Extensions[0,1]? Fetching and playing the various audio formats is a bit outside the purview of Web Audio. But you can feed streaming MSE into Web Audio. If I recall, you use Web Audio's `AudioContext.createMediaElementSource()` to use a (potentially chunked) MSE source with web audio, but it's been a while since I did this. That said, M…

> Fetching and playing the various audio formats is a bit outside the purview of Web Audio Just looking at that clause makes me think perhaps the Web Audio API should have been called something else. Can you imagine writing "fetching and displaying various image formats is a bit outside the purview of HTML"? (I realize that's a bit apples 'n oranges.)

I think it's more like "fetching and displaying various image formats is outside the purview of HTML5 canvas".

If you want to just show an image, you use an tag, or just play an audio file you use . Canvas and the Web Audio APIs are for pages that want to make or mix their own images/audio. Though to be fair, html/javascript do make it easy to load image data from an image tag directly into a canvas; maybe there's a missing parallel for audio.

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

#138
I briefly tried Web Audio to implement a Karplus-Strong synthesizer (about the simplest thing in audio synthesis I guess?).

Without using ScriptProcessorNode, there was no way of tuning the synthesizer because of the limitation that any loop in the audio graph has a 128 samples delay at least.

Maybe a more "compilation-oriented" handling of the audio graphs (at the user's choice) could help overcome this?

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

#140
post #133

Earlier quoted context omitted.

That... explains why Google was so keen to kill off the Audio Data API Mozilla proposed, I guess.

But Chrome for Android didn't come out until 2012 and Chris Rogers started the Web Audio work in 2009. I think someone would have had to have been exceptionally farsighted to think "Android's audio stack is going to suck for several years so we need to design around that now".

At that point in time, though, you could be forgiven with "Sheesh. Javascript is so painfully slow that nobody will ever pass PCM samples around in it."

So, at every point in time up to and including now, you've always got something resisting low-latency PCM. Android is just the latest reason.

Side note: it looks like Chris Rogers bowed out of Web Audio about 2012/2013 timeframe.

Post reply on HN