Fix handling of stereo audio within audiodelays when freq_shift=True
#9876
Conversation
…_shift=False` to avoid `echo_buffer_len=0` when `delay_ms` is invalid within constructor.
…=2` and remove unnecessary position variables.
|
I feel your pain about single_channel_output. As far as I can tell from source code searches this was needed by samd51 analog AudioOut but not any other audio output, and we should restructure things so that not every audio source has to bear a code size and complication cost for it. |
|
From what I recall audio is either stored for mono in I2SOut does handle taking mono samples and making them stereo by sending each sample out twice. How it does that depends on the underlying platform. For RP devices the way the PIO works it does this automatically (it is documented in the code). For SAMD I believe it does this via code. In the code I wrote (and some of the other audio code I have seen) I just checked the channels for 1 or 2 and as long as the main buffer and echo buffer both used the same the Left/Right channels matched. But you have to make sure your total # of samples matches as well (44.1Khz would be 88.2K samples for stereo). I have wondered if simplifying how mono/stereo and bit depth is handled would make things both easier to right and smaller, though potentially at a cost of useability on smaller / older controllers. |
@gamblor21 @jepler for interest.
This has been an issue that I've been aware of since the inclusion of
audiodelaysin 9.2.0. Echo buffer positions weren't being properly managed when handling stereo input/output. I've resolved this issue by separating the echo buffer into two halves (left + right) and offsetting the buffer where necessary. I've done my best to supportsingle_channel_outputas well, but I'm not exactly sure how to test that (I2SOut uses left/right pairs).I've also found a minor bug when constructing
audiodelays.Echowithdelay_ms <= 0 || delay_ms > max_delay_mswhereecho_buffer_lengthwould not be set and remain as the default of 0. The effect of this issue wasn't too major, but I've resolved it by always settingecho_buffer_lengthduringrecalculate_delayand limiting it to the acceptable range.Because each
freq_shiftmode handles the buffer differently now, I've added it so that the fullecho_bufferand buffer positions are reset whenever the mode is changed to avoid potential audio abnormalities.The example in #9874 now does not exhibit any issues. I've also tested this code with variable
delay_msvalues, and the frequency shifting works with full channel separation.Fixes #9874.