To handle decoding and the overhead of moving bits around, it uses a dual-buffer DMA approach. It reads data from an SD card, running the decoding routine on the main CPU. The decoded samples are written into one of two buffers. While one buffer is being written to, the other is read via DMA and sent to the PWM buffer (more on PWM audio here: https://x.com/beala/status/1826147833168408738). Because DMA is used, data transfer can occur in parallel with decoding, without involving the main processor. When the bits have all been written to the PWM buffer, an interrupt triggers a buffer swap, and the process repeats.
I'm leaving out many details. Tuning the pwm speed to achieve correct playback speed was quite an adventure. And when I needed to increase the clock speed to play higher sample rates, this caused I/O errors with the SD card that I never managed to solve. Although I learned a lot from this process, I ultimately opted to use an MP3 module in my final build: https://store-usa.arduino.cc/products/dfplayer-a-mini-mp3-pl...
This is probably routine for an experienced embedded engineer, but it was quite a learning experience for me!
Presumably if a RP2040 could almost do it, a RP2350 could do it no problem. Unless you were limited by PWM speed. Even then you might be able to accept less resolution and filter and dither.
I have a Rust crate for outputting I2S data, or retrieving it from something like a mic or ADC. You can hook it up to DMA and make your audio go brrrr
https://github.com/bschwind/sleep-machine/blob/main/src/main...
Maybe it's my fault for not making it to page 1357 (!) of the datasheet, where the issue is described as "RP2350-E9".
https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...
They don't work at all? How the heck did something that important get past testing?
Guess I'm not moving on from the RP2040 anytime soon...
Because that's how all hardware is; I complained about this sort of thing a few days ago: https://news.ycombinator.com/item?id=43202090
> Guess I'm not moving on from the RP2040 anytime soon...
Doesn't matter what you move to, there's still going to be 2000 pages of datasheets+errata, and one line in the middle of all of that will tell you "This does not work".
That's why for hobbyists it's best to stick to devices with a large community around them, who surface niche problems in community forums.
However, with everyone moving to Discord, this will no longer be useful too...
It has thre DIP switches that set the mode, you can use them to set the playback modes, one of which is serial control, meaning you can easily beef this up using a microcontroller.
I built motion activated playback speakers - good for hiding them in the bushes on halloween.
Great that the author chose one and finished (and published) the project instead of stopping at that annoying junction :)
If you want to smooth the things out because you target a line input, simple LC filter will work just fine here.
Like this: https://shorturl.at/z3eYG (link to Falstad's Analog Filter Tool)
If you want to get better bit depth, you should use PDM instead of PWM.
I still find the principal question of "if I need additional components anyway, should I just get the more complex ones" interesting. It's located somewhere between quality, price, the definition of simple and optimal, as well as one of ones personal (or this week's) perspective on the art of the craft.
The projects is not a discrete player that basically pushes SD card data via a few digital standard ICs out as PWM, it uses a pretty sophisticated MCU after all. So, is a I2S DAC the logical solution or the fast PWM, I still find it hard to decide, especially when i have to order (even the simple or mechanical) parts anyway, or should I have a few I2S DACs in the drawer with the Pico these days.
Not sure if I can bring that point across. It's more about what are your default parts these days. I always have a few i2c OLED displays in that drawer, and the project uses one, too, thirty years ago it might have been resistors, LEDs and a few logic ICs instead. So I wonder, would I go discrete (or "simple") for that particular part of the solution for a particular reason or not. And also, why do I still have no I2S DACs stocked in that drawer, while I have display, sensors etc.
So maybe it's just about audio being a somehow ignored interface in (my) embedded tinkering. Or it's more general and about a modernized selection of stocked parts and using those more naturally while still being aware of the simpler solutions. I use pretty complex (but inexpensive) I2C sensors these days, after all.
Ok, many words on that small part of the overall decision making...
So here are my results up until now:
- The best device I found is a LicheeRV Nano[1] - also used in NanoKVM.
- It has enough CPU+RAM to support more complex formats like FLAC while still being very small.
- It has a full featured MIPI 31-pin / 6-pin touch display port, although I could not find any available display smaller than 7" to order without hassle (there is an unavailable official 3" though[4]).
- It also has USB-C, where it should be possible to use one of these external USB-C to audiojack adapters with mic support.
- Some of these adapters should support headset control buttons out of the box (via kernel usbsound) - on my notebook this works flawlessly.
- There also is a full featured configurable buildroot[2], so, less work to get started with an optimized build.
- Combining a TP4057 battery charger and a battery gauge (MAX17043) you should be able to support a 1200mah battery, read out battery status via I2C and recharge within a < 3" 3D printed case.
- All you would have to do is create a custom buildroot and a nice user interface via LVGL, they already have a music player sample on there samples listing[3]. Unfortunately this is where the workload is huge ;)
1: https://wiki.sipeed.com/hardware/en/lichee/RV_Nano/1_intro.h...
2: https://github.com/sipeed/LicheeRV-Nano-Build
3: https://github.com/lvgl/lv_demos/tree/master/src/lv_demo_mus...
Not to talk down anyone’s hobby project, but that kinda limits the appeal for most other people I would think?
It turns out there is https://www.electricity-magnetism.org/magnetic-storage-devic... -- its a bit more complicated than what I'm more familiar with, which is film-grain-to-digital-equivalent resolution.
Anyway, you could do the work to work out the bit depth/signal rate you'd need to equate to reproduction of a given fluxdensity/recording rate. I would bet the numbers for classic PCM/PDM devices line up surprisingly close to certain tape systems.
On the flipside, once you know those numbers, you could also calculate what the expected analog equivalents could be, sample existing analog media/playback systems and use those to systematically characterize their quality, instead of going by earfeel, as it were.