Clock Radio
FLAC Decoder Test
Something... has gone wrong
That's better.
I had misunderstood how the decoder API works. I thought it gave you a buffer of samples already L/R interleaved. But what it gives you is actually an array of arrays, one for each channel. So what I was doing was splitting the samples for one channel between both channels, speeding it up by 2x.
Then I messed up by only sending half the buffer out to I2S, which had the effect of playing faster but with what sounded more like the correct pitch. That's effectively kind of like a granular distortion.
I did have to speed up the SD access to make this work. The line between SPI and MMC is kind of blurry in the ESP-IDF so I tried setting a host speed field that turned out to be irrelevant! No matter how fast I set it, it would not read any faster (but strangely, leaving it at its default would cause initialization failures). Once I found the knob for the SPI host, all was well. I think the default was 400KHz. 1.6MHz works fine, and there's a ton of headroom to go faster if need be. So the I/O checks out. ✅
I gotta say FLAC was a little easier to work with. It's fundamentally a far more flexible library, plus it had actual documentation so that was a plus.
I also enabled task statistics in FreeRTOS to see where my bottleneck was. It confirmed slow I/O with about 80% of the time being spent in IDLE.
This is what it looks like now, for MP3 decoding — "main" is the decoder, "read_task" is doing the I/O work.
IDLE 7012862 67%
main 2687317 25%
read_task 407110 3%
esp_timer 278046 2%
task list 2699 <1%
and FLAC:
IDLE 7776268 74%
read_task 1465236 14%
main 865944 8%
esp_timer 278624 2%
task list 2540 <1%
So still a pretty substantial amount of CPU time available.