Reconsider maximum allowed channel count (currently 32)

[orottier]

See ircam-ismm/node-web-audio-api#159

Let's benchmark changing

pub struct AudioRenderQuantum {
    channels: ArrayVec<AudioRenderQuantumChannel, MAX_CHANNELS>,
...

To

pub struct AudioRenderQuantum {
    channels: SmallVec<[AudioRenderQuantumChannel; 2]>, // 2, or 4, 5, 8 or any other well known channel count

SmallVec will spill to the heap if the initial capacity is exceeded. So buffers with channel count < X will be put on the stack, larger ones on the heap. This will hurt our allocation-free-rendering but it will effectively remove the limit on the number of channels.

Some more usage of MAX_CHANNELS or assert_valid_number_of_channels should be reviewed. The io abstractions and some nodes use it.

[orottier]

Mixed results, but nothing to severe when changing to SmallVec<[AudioRenderQuantumChannel; 2]>

     Running benches/my_benchmark.rs (target/release/deps/my_benchmark-f1a30677596e9ef0)
bench_ctor              time:   [536.28 µs 542.47 µs 550.18 µs]
                        change: [+0.1613% +1.3675% +2.5806%] (p = 0.03 < 0.05)

bench_audio_buffer_decode
                        time:   [8.4325 µs 8.4464 µs 8.4610 µs]
                        change: [+0.9257% +1.2399% +1.5521%] (p = 0.00 < 0.05)
                        Change within noise threshold.

bench_constant_source   time:   [849.06 µs 856.09 µs 863.80 µs]
                        change: [-1.9171% -1.0192% -0.1462%] (p = 0.03 < 0.05)
                        Change within noise threshold.

bench_sine              time:   [3.4638 ms 3.4711 ms 3.4792 ms]
                        change: [-2.4185% -2.1462% -1.8583%] (p = 0.00 < 0.05)
                        Performance has improved.

bench_sine_gain         time:   [3.7062 ms 3.7186 ms 3.7317 ms]
                        change: [-3.3107% -2.9381% -2.5500%] (p = 0.00 < 0.05)
                        Performance has improved.

bench_sine_gain_delay   time:   [5.9413 ms 5.9450 ms 5.9490 ms]
                        change: [-0.7370% -0.5908% -0.4500%] (p = 0.00 < 0.05)
                        Change within noise threshold.

Benchmarking bench_buffer_src: Warming up for 3.0000 s
bench_buffer_src        time:   [1.1732 ms 1.1762 ms 1.1793 ms]
                        change: [+2.7967% +3.3924% +3.9657%] (p = 0.00 < 0.05)
                        Performance has regressed.

bench_buffer_src_delay  time:   [4.5713 ms 4.5790 ms 4.5868 ms]
                        change: [+5.7627% +6.0800% +6.3788%] (p = 0.00 < 0.05)
                        Performance has regressed.

bench_buffer_src_iir    time:   [7.9396 ms 7.9467 ms 7.9544 ms]
                        change: [-0.1389% +0.0205% +0.1742%] (p = 0.80 > 0.05)
                        No change in performance detected.

bench_buffer_src_biquad time:   [5.0991 ms 5.1090 ms 5.1194 ms]
                        change: [-2.5902% -2.1273% -1.7022%] (p = 0.00 < 0.05)
                        Performance has improved.

bench_stereo_positional time:   [2.7467 ms 2.7512 ms 2.7561 ms]
                        change: [-3.4649% -3.1396% -2.8468%] (p = 0.00 < 0.05)
                        Performance has improved.

Benchmarking bench_stereo_panning_automation: Warming up for 3.0000 s
bench_stereo_panning_automation
                        time:   [1.4794 ms 1.4831 ms 1.4872 ms]
                        change: [-3.3337% -2.9802% -2.5985%] (p = 0.00 < 0.05)
                        Performance has improved.

bench_analyser_node     time:   [2.1406 ms 2.1439 ms 2.1475 ms]
                        change: [+0.9607% +1.4687% +1.8379%] (p = 0.00 < 0.05)
                        Change within noise threshold.

bench_hrtf_panners      time:   [27.520 ms 27.583 ms 27.662 ms]
                        change: [-0.4894% -0.2063% +0.1106%] (p = 0.21 > 0.05)
                        No change in performance detected.

bench_sine_gain_with_worklet
                        time:   [3.9113 ms 3.9196 ms 3.9284 ms]
                        change: [-0.2906% +0.0492% +0.3768%] (p = 0.78 > 0.05)
                        No change in performance detected.

Changing to 4 inline channels regresses performance (compared to 2 channels) very slightly - around 2%

I should probably add a benchmark using high channel count processing