It's slower, but... does it matter if it's not just "slow"? Slower than "so fast" is still "fast".
> and more involved
That's right.
> Also, unless you're going to be using WAVs, there's going to be some overhead for the decoding of the sound.
If I recall correctly, Firefox's Audio Data API does the decoding for you and provides the final PCM samples even when loading non-WAV formats.
> Also, the filter won't be very high order since you're going to be doing at least n 44100 operations per second
If the effect computation is a problem, you can pre-render it in a buffer.
Anyways, n*44100 operations per second is not that much. You actually operate on buffers, which makes caching useful for the slow part (memory access). Summing, multiplying, etc. is a piece of cake for your CPU in JIT-compiled code.
Check this JSFiddle I threw in a couple minutes: http://jsfiddle.net/9LpKd/2/ (please mind the awful effect and the fact that it's not audio... I'm not very experienced with Audio Data API and that would take me a bit more to fiddle with!)
44000 pixel updates, up to 60 times a second, with pretty expensive operations (sines, cosines and even square roots!), updating DOM values... JavaScript is fast enough for this.
I can see the problem in mobile devices though, but I'm not even sure Firefox provides Audio Data API in mobile devices.
>Do you have examples of the above working in Firefox? I'd be curious to see the implementation.
The only web implementing it that I can remember is http://websdr.ewi.utwente.nl:8901/ (you have to check the HTML5 audio radio button).
Unfortunately the code is minified and it takes a bit to make sense of it after Beautifying.
It's slower, but... does it matter if it's not just "slow"? Slower than "so fast" is still "fast".
> and more involved
That's right.
> Also, unless you're going to be using WAVs, there's going to be some overhead for the decoding of the sound.
If I recall correctly, Firefox's Audio Data API does the decoding for you and provides the final PCM samples even when loading non-WAV formats.
> Also, the filter won't be very high order since you're going to be doing at least n 44100 operations per second
If the effect computation is a problem, you can pre-render it in a buffer.
Anyways, n*44100 operations per second is not that much. You actually operate on buffers, which makes caching useful for the slow part (memory access). Summing, multiplying, etc. is a piece of cake for your CPU in JIT-compiled code.
Check this JSFiddle I threw in a couple minutes: http://jsfiddle.net/9LpKd/2/ (please mind the awful effect and the fact that it's not audio... I'm not very experienced with Audio Data API and that would take me a bit more to fiddle with!)
44000 pixel updates, up to 60 times a second, with pretty expensive operations (sines, cosines and even square roots!), updating DOM values... JavaScript is fast enough for this.
I can see the problem in mobile devices though, but I'm not even sure Firefox provides Audio Data API in mobile devices.
>Do you have examples of the above working in Firefox? I'd be curious to see the implementation.
The only web implementing it that I can remember is http://websdr.ewi.utwente.nl:8901/ (you have to check the HTML5 audio radio button).
Unfortunately the code is minified and it takes a bit to make sense of it after Beautifying.