[HN Gopher] Raspberry Pi Pico audio player
       ___________________________________________________________________
        
       Raspberry Pi Pico audio player
        
       Author : zdw
       Score  : 109 points
       Date   : 2025-03-02 14:29 UTC (8 hours ago)
        
 (HTM) web link (lucstechblog.blogspot.com)
 (TXT) w3m dump (lucstechblog.blogspot.com)
        
       | josteink wrote:
       | Am I understanding that this project is limited to play 8kHz
       | samples wave-files, ie only up to 4kHz real world? Is that even
       | tape-quality?
       | 
       | Not to talk down anyone's hobby project, but that kinda limits
       | the appeal for most other people I would think?
        
         | duped wrote:
         | That's the (lowest) sample rate on telephone networks, so no.
         | Way worse than tape.
        
           | 6stringmerc wrote:
           | Was giving this thought as well and realized this is more in
           | line with building a "crystal radio" type project than aiming
           | for a marketable product. It's a case study of a learning
           | process, which is pretty spiffy to me.
        
         | smitelli wrote:
         | Analog tape can sound pretty damn good, depending on the total
         | surface area used and how fast it moves past the record/play
         | heads.
        
           | vetrom wrote:
           | Isn't there some way you could calculate the signal density
           | you'd need in any of PDM/PWM/PCM to roughly equate to the
           | quality of signal reproduction of a given tape media, given
           | known tape surface/speed/magnetic density?
           | 
           | 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.
        
         | relwin wrote:
         | I've got a Pico 2 (2035) playing mono 22kHz MP3 using built-in
         | 12-bit PWM, sounds pretty good. This would probably work on the
         | 2040. However, as this is C code I'm not sure if this ports to
         | MicroPython easily.
        
       | atoav wrote:
       | If you want to do a similar audio player I can recommend the DY-
       | SV5W module family, this is essentially a micro-SD playback chip
       | with a headphone amp and a 5W (mono) amplifier, the whole thing
       | can be powered from 5V/USB. Really great for art projects where
       | you just need a single track to play/loop on the press of a
       | button and can't be bothered to program.
       | 
       | 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.
        
         | JansjoFromIkea wrote:
         | Thanks for this, wasn't exactly looking for something like this
         | but it fits a bunch of projects I have in mind!
        
         | schobi wrote:
         | Similarly, the dfplayer mini is fine if you want some sound to
         | scream back at you. Works on button press, but also rx/TX for
         | track management from micro SD card. Small amplifier built in.
         | 
         | I built motion activated playback speakers - good for hiding
         | them in the bushes on halloween.
        
       | bschwindHN wrote:
       | The RP2040 can output 24 bit (or technically 32-bit), 48kHz
       | stereo audio over I2S. Combine that with a DAC like the PCM1502
       | (which has plenty of dev boards) and you've got yourself a high
       | quality audio setup.
       | 
       | 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/rp2040-i2s
        
       | hoc wrote:
       | Due to the missing DAC on the Pico this always runs into that
       | fully discrete vs. resistor ladder/network vs. external dac (i2s
       | or other) decision.
       | 
       | Great that the author chose one and finished (and published) the
       | project instead of stopping at that annoying junction :)
        
         | mordae wrote:
         | For headphone audio it's plenty to just PWM, inductance of the
         | headphones and mechanical low pass characteristic of the
         | speaker itself will mostly do the rest.
         | 
         | 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.
        
       | nerdralph wrote:
       | I think schematics are easier to read than looking at a
       | (fritzing?) breadboard layout. Discrete resistors aren't
       | necessary for the buttons if you enable the internal pullups on
       | the RP2040.
        
         | boznz wrote:
         | This. Also still waiting for AI to be able to read schematics,
         | its going to make my life so much easier.
        
       | beala wrote:
       | I wanted to create an mp3 player (not just wav) using a pico and
       | found this repository very instructive:
       | https://github.com/ikjordan/picosounds
       | 
       | 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!
        
       | tyre wrote:
       | Plug for Shareplay, which turns a raspberry pi into an airplay
       | server so you can connect non-Airplay speakers:
       | 
       | https://github.com/mikebrady/shairport-sync
        
         | oliwarner wrote:
         | Not on a Pico though.
        
           | deivid wrote:
           | You could connect airplay to snapcast[0] then use an embedded
           | snapcast player, like mine[1], I do this on an ESP32 with
           | 320KiB of SRAM
           | 
           | [0]: https://github.com/badaix/snapcast
           | 
           | [1]: https://github.com/davidventura/esp-snapcast
        
       | slig wrote:
       | Last week YouTube recommended a video about a Logic Analyzer
       | using the Pi Pico. Had no idea it was that powerful.
        
       | 34679 wrote:
       | I feel like the flaws of the Pico 2/RP2350 should be advertised
       | better. The Pico is great. I waisted half of an extremely
       | frustrating day with a Pico 2 before suspecting the board itself
       | was the problem, and confirming it with very specific searches
       | that brought up threads about the issue. The internal pull-downs
       | don't work.
       | 
       | 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...
        
         | wilted-iris wrote:
         | This is unfortunately not emphasized with many breakout boards.
         | It pays off to skim errata sections at the start of a project.
         | All hardware has errata, and it ranges from incorrect details
         | and minor malfunctions all the way through to broken
         | peripherals and all manner of critical malfunctions.
        
           | beala wrote:
           | To be clear, this isn't a problem with the breakout board.
           | The issue is inside the microcontroller itself, which, iiuc,
           | is why there is such a long lead time on fixing it.
        
         | slabity wrote:
         | > The internal pull-downs don't work.
         | 
         | 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...
        
           | monocasa wrote:
           | Yeah, it's an A0 flaw. Word on the streets is that it was
           | from modifying the pads to be 5V tolerant.
        
       ___________________________________________________________________
       (page generated 2025-03-02 23:00 UTC)