The sample rate for microphone input via `StreamSplitter` must be an integer multiple of existing sample rate

[dpgeorge]

In MicroPython we need to record samples from the microphone at a rate of 7812Hz, to be compatible with the output sample rate on micro:bit v1.

Creating a SplitterChannel and then calling SplitterChannel::requestSampleRate(7812) does not do anything. The internal logic is currently:

• compute required period via 1000000/7812, which is 128
• that period is bigger than the existing sample period of 90 (corresponding to a sample rate of 11111Hz)
• so, the period is not changed, and the SplitterChannel assumes it can down-sample the 11111Hz to 7812Hz
• in SplitterChannel::pull() it attempts to do this down-sampling, but the algorithm there is very simple and it can only drop every N samples, where N is an integer (in this case step is 11111/7812=1.42 which is rounded down to 1)
• the data is then passed down at a rate of 11111Hz, instead of 7812Hz

To get the desired rate of 7812Hz I can do:

• SplitterChannel::requestSampleRate(7812*2)
• SplitterChannel::requestSampleRate(7812)

That works because the first call requires a sample period of 64 which is smaller than the existing value of 90. So the sample period is decreased to 64. Then the second call to requestSampleRate() doesn't change the sample period, but does mean the down-sampling is now an exact multiple of the sample rate and so SplitterChannel::pull() can drop every second sample. Thus we get a rate of 7812Hz.

But, now the component that needs 11111Hz (I think it's the SPL) is going to get 7812*2=15624Hz, and probably won't work correctly anymore.

---

A suggested fix would be for SplitterChannel::pull() to have a more sophisticated down-sampling algorithm with a fractional step value, and averaging instead of dropping samples. Eg, average 2 samples, copy 1 sample, average 2 samples, copy 2 samples, then repeat. That case would turn 7 samples into 5, so convert a rate of 11111Hz into 7936Hz.

[JohnVidler]

This is no longer the case as of v0.2.65, as the SplitterChannel class actively resamples the stream to the requested rate.

Note that some extremely small values won't be possible (like requesting a 1Hz sample rate) with the lower bound bottoming out around 45-128Hz as the minimum lambda for any signal is proportional to the length of the buffer received. If truly tiny frequencies are required, additional buffering would be required as the SplitterChannel right now (by design) only handles 1 buffer at once to limit RAM usage.

[dpgeorge]

I can confirm that this is now fixed (tested using CODAL 0.2.66).