-
Notifications
You must be signed in to change notification settings - Fork 2
Open
Description
The problem
Running the filter-bank is fairly slow. It would be nice to measure the two big cost-centers:
- Running the ConvolverNode (128 samples/buffer, ~300 runs/sec, 60 nodes/cochlea, native)
- Running the AnalyserNode (2048 samples/buffer, ? runs/sec, 60 nodes/cochlea native)
- Computing the power (2048 samples/buffer, 30fps runs/sec, 60 nodes/cochlea, Javascript & TypedArray)
Doing everything together, 60 filters can run with 2048 sample-long analysers at 30fps in Chrome; not quite fast enough in Firefox. We want more :)
Some ideas for optimizing the power computation (suspected bottleneck, not tested)
- Unroll the loop We know that the analyser buffer will always be a multiple of 128, so we can pretty aggressively loop-unroll when squaring and summing all of the samples. Loop unrolling in js seems to be very effective sometimes
- Cache the loop length a'la jsperf report
- Reuse an AudioBuffer rather than instantiating a new one for each power computation (30 fps * 60 allocations/frame = 1800 allocations per second)
Curiosities
- The AnalyserNode provides four functions:
getByteFrequencyData(),getFloatFrequencyData(),getByteTimeDomainData(), andgetFloatTimeDomainData(). Does the node compute the buffers for all of these measures, or are they only lazy computed from a single source on demand? - The ConvolverNode allows the use of only real-valued kernels. If we want to convolve with arbitrary (complex-valued) kernels, we would have to replace the ConvolverNode with a Javascript convolution. This would probably be very much slower than the native convolution done in a ConvolverNode. Will this be possible?
Metadata
Metadata
Assignees
Labels
No labels