Skip to content

Performance #1

@imalsogreg

Description

@imalsogreg

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(), and getFloatTimeDomainData(). 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions