3 ms·

Ah yes, looking at the source code makes it a bit obscure, because the inheritance patterns are described in the wrappers. But for generators, you can do, for e

Ah yes, looking at the source code makes it a bit obscure, because the inheritance patterns are described in the wrappers. But for generators, you can do, for example osc.append(buffer, channelCount);, because generators are by nature multi-channel, but for effects you have to create a multi-channel instance, like flt = audioLib.LP12Filter.createBufferBased(channelCount, sampleRate, cutoff); and then you can use the append function similarily to generators. This is a design choice to make implementing new effects simple, and the framework providing this extra functionality for you.

aaronblohowiak 15y ago
I see that you have layered a Buffer-style API on top of your per-sample code (api-buffer-effects.js), and I could still be missing something, but it looks like that just automates the call to process each sample individually -- //api-buffer-effect self.effects[n].pushSample(buffer[i + n], 0); //api-generator out[i + n] = this.getMix(n) * this.mix + buffer[i + n]; This is very different from being able to process batches of samples within your effect or osc code -- even if the JIT inlines the functions of this.mix, you will still incur unnecessary setup cost. Of course, without profiling this is just speculation.
- quinnirill 15y ago
  Yep, I definitely see where you're coming from with this. It was my initial take as well, but as crazy as it is, after some time spent comparing different approaches, turned out that this is the fastest way to do it in JavaScript world, and that is true even up to older browsers such as IE8 (I haven't bothered measuring anything related in browsers older than that, because IE8 is the oldest browser with some way to output generated sound), but especially true with the latest optimizations such as CrankShaft. However, I should probably set up some public performance tests and compare the instructions these things compile to have some hard data back my claims, I wouldn't exactly trust me just saying it is so, as I have just tested these things on the fly. But, however, this approach is more modular, and fits more use cases, and that matters even more for me right now, but trust me, I've spent my time optimizing every operation to the point that it doesn't make things harder to use. :)
  - aaronblohowiak 15y ago
    Very cool! It is so exciting to see jit technology improve so much. In C, it is definitely faster to go in batches -- having things in batches in C also makes it easy tO plug in vector libraries if available on the current platform. I would love to see your performance benchmarks.

aaronblohowiak 15y ago

I see that you have layered a Buffer-style API on top of your per-sample code (api-buffer-effects.js), and I could still be missing something, but it looks like that just automates the call to process each sample individually -- //api-buffer-effect self.effects[n].pushSample(buffer[i + n], 0); //api-generator out[i + n] = this.getMix(n) * this.mix + buffer[i + n]; This is very different from being able to process batches of samples within your effect or osc code -- even if the JIT inlines the functions of this.mix, you will still incur unnecessary setup cost. Of course, without profiling this is just speculation.

quinnirill 15y ago
Yep, I definitely see where you're coming from with this. It was my initial take as well, but as crazy as it is, after some time spent comparing different approaches, turned out that this is the fastest way to do it in JavaScript world, and that is true even up to older browsers such as IE8 (I haven't bothered measuring anything related in browsers older than that, because IE8 is the oldest browser with some way to output generated sound), but especially true with the latest optimizations such as CrankShaft. However, I should probably set up some public performance tests and compare the instructions these things compile to have some hard data back my claims, I wouldn't exactly trust me just saying it is so, as I have just tested these things on the fly. But, however, this approach is more modular, and fits more use cases, and that matters even more for me right now, but trust me, I've spent my time optimizing every operation to the point that it doesn't make things harder to use. :)
- aaronblohowiak 15y ago
  Very cool! It is so exciting to see jit technology improve so much. In C, it is definitely faster to go in batches -- having things in batches in C also makes it easy tO plug in vector libraries if available on the current platform. I would love to see your performance benchmarks.