91–100 of 179 posts
Are there any good audio APIs out there? Video AND audio? They good you all covered with nice APIs! Just audio? You're screwed!
Earlier quoted context omitted.
You're making music. It's not that difficult. http://kruhft.bandcamp.com/ Here's a synth using the technique: http://busfactor1.ca/kruhft
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.
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 strongly agree with the author. I will second this. I wanted to make a live streaming playback feature using the API so I could remotely monitor an audio matrix/routing system that I have in the office. The API has _zero_ provision for streaming MP3. You either load and playback a complete MP3 file or you get corrupted playback because the API simply won't maintain state between decoding calls. What I ended up ha…
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, Media Source Extensions (MSE) is only supported on relatively modern browsers (IE11+) but you should be able to use it to stream mp3 to the Web Audio API on supported browsers.
There's also a way to do this without using MSE for older browsers. See the 72lions repo below for an example[2]. It's a bit convoluted, but not as much work as your workaround. As described in the README of the 72lions proof-of-concept:
"The moment the first part is loaded then the playback starts immediately and it loads the second part. When the second part is loaded then then I create a new AudioBuffer by combining the old and the new, and I change the buffer of the AudioSourceNode with the new one. At that point I start playing again from the new AudioBuffer."
0. https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...
Isn't Web Audio based off of MacOS'x Audio API? I think the whole point is that Javascript used to be slow, and using the CPU as a DSP to process samples prevents acceleration. Seems to me what is needed is like "audio shaders" equivalent to compute/pixel shaders, that you farm off to OpenAL-like API which can be compiled to run on native HW. Even if you grant emscripten produces reasonable code, it's still bloated,…
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 la…
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…
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.
Partially because in addition to the interface itself it relies on a bunch of generic worklet machinery which also doesn't exist in any browser and is not trivial to implement in non-sucky ways.
But also partially because the spec has kept mutating, so no one wants to spend time implementing until there's some indication that maybe that will stop.
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…
Within that constraint I don't think it's a terrible API, but it's a big constraint and naturally raw access would be far preferable.
One thing that really irks me at the moment is the huge variation in sound volume of the increasing plethora of videos in my social media feed. If there was some way we could use a real time WebAudio manipulation on the browser to equalise the volume on all these home made videos, so much the better. Not just volume up/down, but things like real time audio compression to make vocals stand out a little.
Add delay and reverb to talk tracks etc. for podcasts.
EQ filters to reduce white noise on outdoor videos etc. also would be better. People with hearing difficulties in particular ranges, or who suffer from tinnitus etc. would be able to reduce certain frequencies via parametric equalisation.
It would be intriguing to see a podcast service or SoundCloud etc. offer real time audio manipulation, or let you add post processing mastering effects on your audio productions before releasing them in the wild.
Earlier quoted context omitted.
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…
> OpenAL is a closed-source library So are all official OpenGL implementations (MESA isn't official, last I heard). Doesn't stop them from being a standard and being used, although I agree they would be better if they were open source.