[Linux] RMS ring buffer producing non-silent values when only silence has been inserted.

[mitchmindtree]

It looks like this might only be happening while testing on linux due to ALSA's need for exclusive access to the current audio output device, however writing this up just for the record.

Was able to confirm using assert!ions at the beginning of sample::Rms::next, so the issue is definitely not due to non-silent values sneaking into the buffer some how. Current theory is that some kind of undefined behaviour within the cpal ALSA backend is either 1. corrupting the stack somehow and causing the EnvDetector's RMS window pointer to point to something else or 2. causing some pointer to write over the RMS window's region of memory.

If that's not the case, then there must be some bug in the sample::ring_buffer implementation, however even when removing all unsafe code from the ring_buffer implementation this bug still occurs.