Closed microbit-carlos closed 7 months ago
I can confirm that with CODAL v0.2.55 this is issue is still present: MICROBIT.hex.zip
#include "MicroBit.h"
#include "StreamRecording.h"
MicroBit uBit;
static const int SAMPLE_RATE = 7000;
static void onButtonLogo(MicroBitEvent) {
static SplitterChannel *splitterChannel = uBit.audio.splitter->createChannel();
splitterChannel->requestSampleRate(SAMPLE_RATE);
static StreamRecording *recording = new StreamRecording(*splitterChannel);
static MixerChannel *channel = uBit.audio.mixer.addChannel(*recording, SAMPLE_RATE);
MicroBitAudio::requestActivation();
channel->setVolume(75.0);
recording->recordAsync();
while (uBit.logo.isPressed() && recording->isRecording()) {
uBit.display.print("R");
uBit.sleep(150);
}
recording->stop();
uBit.display.clear();
recording->play();
while (recording->isPlaying()) {
uBit.sleep(20);
}
recording->erase();
}
int main() {
uBit.init();
uBit.messageBus.listen(MICROBIT_ID_LOGO, MICROBIT_BUTTON_EVT_DOWN, onButtonLogo);
while (true) {
uBit.sleep(100);
}
}
Edit: Ensuring I'm using the latest commits from all dependencies and I can still replicate this issue.
I've given a more complete update over in https://github.com/lancaster-university/codal-microbit-v2/issues/356 but the gist is that this should no longer be the case when we merge the test branch(es) into master as the SplitterChannels should now automatically resample to match the requested rates.
Thanks everyone for being patient on these issues.
Barring the extreme lower end of the frequency scale ( <128Hz ) we should no longer see this as of v0.2.65 provided data is slowing through a SplitterChannel; which it pretty much always is for user applications :)
If I set it to 11000 or 5500 it seems to work fine, but if I set it to 8000 (haven't tried other values yet) the recording playback seems slowed down.
To test it i've used a metronome up at something like 150 BMP, record it and tried to match the playback. Voice recordings also sound a bit deeper.
5500.hex.zip 8000.hex.zip