Fix audio sample rate on rp2040 #5218
Conversation
I noticed that the loop over 65535 possible denominators took a long time, causing up to 100ms wait for a sound sample to start playing! This algorithm, adapted from an algorithm shown in Python's fractions.py, is guaranteed to find the best denominator in a small number of steps (I think log2-many steps but I'm not sure). In practice, it means the time between samples playing is just 10ms, and some of that is recreating the sine wave sample in Python each time. It often finds the same solution as the old code, but sometimes it finds one a bit better since it compares the ratios using float point instead of integer arithmetic.
There was a problem hiding this comment.
I compared limit_denominator() with the Python implementation. I did not try to understand the algorithm, but it looks like an accurate transcription. Does it sound better?
I misunderstood #5092 and was looking at how PWMOut calculates the frequency divisor and top value. It's not that accurate at low frequencies, but I'm not sure it's any worse than other PWMOut impls.
Using |
There's a simple fix, that uses 64 bit arithmetic where necessary. But I chose to make a more complex fix, because I also noticed that it could take up to 100ms for the sample rate to be found! The new algorithm is faster (I think it runs in log(max_denominator) time, sort of like gcd) and can also give slightly more accurate results due to comparing the frequencies as floating point instead of integers—it only makes a difference in cases where the sample rate was already being met to within 1Hz, so not a big difference.
Closes: #5092