Add simulator support for sample rate #5757
Conversation
| } catch (e) { | ||
| state.recording.volume = volume; | ||
|
|
||
| const minPlaybackRate = 0.15 |
There was a problem hiding this comment.
Is there a reason that these aren't defined with the other default variables at the top of the file?
There was a problem hiding this comment.
they're only used in this one spot
| const minPlaybackRate = 0.15 | ||
|
|
||
| let maxPlaybackRate = 15; | ||
| if (isFirefox()) { |
There was a problem hiding this comment.
I know that you said that you were experiencing weirdness with Firefox. Is there a reason why setting this to 8 works for Firefox or was it with testing that this was found to be the value that works on Firefox?
If there is a tangible reason, could we maybe add a comment here for a quick explanation?
There was a problem hiding this comment.
i'll add a comment, but yes i found it by experimenting. 15 was the max playback rate in chrome and 8 was the max in firefox. i didn't try to figure out the max in safari, but 15 worked and that's higher than anyone will be able to detect anyhow.
| const playbackRate = Math.max(minPlaybackRate, | ||
| Math.min( | ||
| maxPlaybackRate, | ||
| bitRateToSampleRate(state.outputBitRate) / bitRateToSampleRate(state.audioURLBitRate) |
There was a problem hiding this comment.
This question might be best asked as what is the relationship between bit rate and sample rate, but I'm going to put here what I'm thinking through.
I know you say below that the browser APIs don't allow us to adjust the sample rate directly and can map in between sample rate and bit rate. If that's the case, why do we need the playback to be the sample rate? Can we just have playback rate be the bit rate?
There was a problem hiding this comment.
bit rate is the sample rate times the bit depth. I couldn't immediately find what the bit depth of the browser's media recorder is, but in any case the sample rate should have a linear relationship with the bit rate. personally, i don't think it's super important that we accurately match the sample rate of the hardware since your computer has a different mic and is going to sound better no matter what; all that matters is that lower sample rate sounds worse and higher sounds better.
the reason i convert back and forth is because we still want the playback rate to be based on the sample rate that the user set. for example, if they set the recording rate to be 11000 and the playback rate to be 22000, the playback rate should be 2.0, but because the bit rate scales differently it would end up being much higher if we used the bit rate instead.
There was a problem hiding this comment.
Ohh, that makes sense. Thanks!
Fixes #5286
This adds simulator support for the sample rate blocks in the audio recording extension.
The new behavior includes:
The recording times vary from 3 seconds at the highest sample rate to 20 seconds at the lowest. I can adjust this range if need be, but those were the values @srietkerk got when testing on hardware.
Also, the browser has limits on how fast/slow you can play audio, so I capped it within a reasonable range; I've tested recording and playback in Chrome + Firefox on Windows and Safari on macOS.
Here's a test URL:
https://makecode.microbit.org/app/8ac1af74a11ed81b3d41f1a0d0eee068d2158fdf-3acc60290d