test k-rate param return buffer of 1 length

[b-ma]

Warning: this is broken

Hey, this is just a rapid test for the k-rate parameters returning a buffer of length 1 (plus minor changes to separate more clearly a-rate logic from the rest).

• From the param point of view, it didn't changed much actually, the test are passing with very minor (and expected) changes.
• Some tests are failing (in AudioBufferSource Delay and WaveShaper) where probably I didn't checked the rate properly, I didn't fixed them for now.

What do you think? should we continue on that vein?

I'm personally not that sure as on the one hand, it will complicate all the nodes rendering to basically just replace a buf.resize(128) with a buf.resize(1), but on the other hand, probably it will allow to improve perf on some points.

So no strong opinion on my side, if you think it worth the case I can explore further what it means for the broken nodes to properly support both k-rate and a-rate, would allow to see the overhead it requires

[orottier]

We should actually return a slice of size 1 here for k-rate obviously. The rest of the buffer is garbage per

        param_computed_values
            .channel_data_mut(0)
            .copy_from_slice(param_intrisic_values);

Where param_intrisic_values is of size 1 only (via tick)

[b-ma]

You are right, didn't spot this one

[orottier]

Hey @b-ma , thanks for trying this out!

I'm also not sure. I think it's a very nice thing to have that the param values are always quantum-sized. This allows you to zip up the input values with the param values which is very convenient.

It should have a very clear code-readability or performance benefit to switch to 1-sized param values. Looking at the diff, I don't see a big change in readability. Not sure about performance but I would doubt if there will be a big change there too..

So at this stage I would say let's keep the original implementation.

[orottier]

We could even go further and make the slice len explicit (no-copy cast to array) like this:

    /// Get the computed values for the given [`crate::param::AudioParam`]
    ///
    /// For both A & K-rate params, it will provide a array of length [`crate::RENDER_QUANTUM_SIZE`]
    pub fn get(&self, index: &AudioParamId) -> &[f32; crate::RENDER_QUANTUM_SIZE] {
        self.get_raw(index).channel_data(0).as_slice().try_into().unwrap()
    }

This makes our promise to always return the full size permanent and unbreakable

[b-ma]

So at this stage I would say let's keep the original implementation.

Yup agreed let's drop that PR, we have probably more important rooms for performance improvements before going to this kind of details

We could even go further and make the slice len explicit (no-copy cast to array) like this

I don't see where we have a copy currently ? Maybe we should try to take into account that it seems that render quantum size could become user-defined at some point (cf. WebAudio/web-audio-api#2450)

[orottier]

I don't see where we have a copy currently ?

We don't! I just wanted to clarify we can change the return type from &[f32] to &[f32; 128] at zero cost.

You raise an interesting point by looking forward to the v2 of the spec. I have some ideas how to make that work with const generics but that would mean a breaking change in our API, forcing us to move to a v2 too. Maybe there's also a possibility without const generics that would be backwards compatible. Exciting times