Fix stereo signal processing within audiofilters.Filter

[relic-se]

Previously, left and right channels of stereo audio data were being treated as mono when processing through audiofilters.Filter. This update properly handles stereo data within this class by separating channel sample data into filter_states and filter_buffer.

For interest, @gamblor21 @todbot

Fixes #11024

[tannewt]

Are there any tests you could expand to test this?

[relic-se]

@tannewt Using the example code provided in #11024 (comment), here are the results of that test:

The stereo waveform graph above adheres to the following settings:

# Recording 1
FILTER = False
FILTER_BYPASS = True

# Recording 2
FILTER = True
FILTER_BYPASS = True

# Recording 3
FILTER = True
FILTER_BYPASS = False

Here's the same test but with varying filter frequencies:

Recording	Filter Frequency (hertz)
1	22050 (nyquist of sample rate)
2	1000
3	100

I can come up with a more objective test if desired. In my subjective opinion, it sounds significantly better in stereo and mono is unaffected.

[relic-se]

@tannewt The code I have provided does work, but I think there is room for optimization if you or someone else is willing to dive into it in a review.

[tannewt]

I know you tested it. I think you can add automated tests for it. See: https://github.com/adafruit/circuitpython/tree/main/tests/circuitpython

What sections do you expect need to be optimized?

[relic-se]

I know you tested it. I think you can add automated tests for it. See: https://github.com/adafruit/circuitpython/tree/main/tests/circuitpython

Okay yes, I see what you mean. The current filter tests on there are in mono. I can add stereo tests to the stack.

What sections do you expect need to be optimized?

Looking back, it's not as rough as I remember. The only segment could be here:

for (uint8_t k = 0; k < self->base.channel_count; k++) {
    synthio_biquad_filter_samples(filter_obj, &self->filter_states[j * self->base.channel_count + k], self->filter_buffer + k * SYNTHIO_MAX_DUR, n_samples);
}

@tannewt Do you think it would be beneficial to avoid the for loop and instead process the left channel (or mono) first and then add an if statement before running the right channel buffer? Since this isn't on a per-sample basis, there are minimal gains to be had, so I'm not stressed about it.

---

This update doesn't explicitly have single channel support. I was having some pointer difficulties at first and reverted the single channel support I had written in to improve debugging.

I can look at adding it back in, but the SAMD51 build doesn't include this module to begin with and there is an existing effort to remove it altogether (#9877). @tannewt Let me know if you would like me to move forward on that support.