Hello. First time posting so I hope you will be kind.

The overarching task is simple: Pico as a server, which downloads and plays, through PAM8302 amplifier, various audio clips ranging in duration from 5 to 55 seconds. The PAM8302 is irrelevant to the decoding, but including to specify that I wish to do this with no other breakout parts (i.e., DFPlayer). The choice to use Pico is cost and design, and the solution on an Ubuntu system (i.e., Zero, Pi 5) is simple.

Here is a brief summary of the state of audio as I understand this:
- MicroPython can perform audio playback of WAV via I2S magic or UART magic which rely on other libraries.
==> e.g. https://github.com/miketeachman/micropy ... s-examples
==> e.g. https://github.com/danjperron/PicoAudioPWM
==> I have not dived deep into its literature, and there are a few other examples which tend to occur in searches.
==> For all intents and purposes I consider WAV playback possible on Pico in MicroPython
==> WAV formats tend to be ballpark 6MB/minute and Pico download speeds tend to be under 1 MB/second
==> This solution is capable of near real-time round trip with a server via audio (i.e., ten seconds between request and TTS vocalization)

- CircuitPython can perform audio playback of MP3 in its Python:
==> this is what confuses me most about forum discussion of MP3 in MicroPython
==> other forum posts discuss using hardware MP3 decoders but these should not be necessary
==> e.g. viewtopic.php?p=2252646
==> other forum posts discuss future support for Pico to handle MP3 native but CircuitPython appears to do this on Pico
==> e.g. https://learn.adafruit.com/mp3-playback-rp2040
==> This is presently the "winning" solution: simplicity with broad scope of additional libraries not available with MicroPython

- MicroPython and CircuitPython can co-exist with an interface of Blinka
==> In a very impressive way, adding several MicroPython files to Pico enables the use of some core MicroPython libraries (e.g. board)
==> e.g. https://learn.adafruit.com/circuitpytho ... -libraries
==> However, the MP3 libraries rely on the core CircuitPython modules called audiopwn and audiomp3 which are not part of the Blinka support
==> As a result, MicroPython cannot support MP3 through Blinka through CircuitPython, and these are core CircuitPython not its library set.
==> e.g. https://circuitpython.org/libraries

All in all the decision seems to be simple:
==> Want to play MP3? Use CircuitPython.

However, I specifically chose MicroPython because the packages are closer to native, and the support for MicroPython is operated by Raspberry Pi and the Pico team, i.e., MicroPython is for all intents and purposes a Raspberry Pi product extension. Blinka for MicroPython is supported by CircuitPython for the purposes of CircuitPython. Also, the prevailing sensibility is that CircuitPython is for toy education programming; whereas, eventually, treating the Pico as a microcontroller for intense (i.e., robotic, closer to real-time, closer to multi-threaded exact timing) operations is what MicroPython is designed to do in this space, to the best abilities of the Pico hardware. That locks me in to MicroPython, although that sensibility does seem to be wavering; and for treating the Pico as a plug-and-play sensor-as-a-service hardware platform, where exactitude is not critical, CircuitPython seems to have closed the systems operations gap to a reasonable degree to make that a default platform language for me.

In short:
==> WAV audio on Pico without additional hardware is solved, though challenging, through software
==> MP3 audio decoding on Pico should be possible with native hardware and MicroPython, but something somewhere is not supported

What is an engineer to do?

Just short correction, Micropython is not actually supported by us, but by the MIcropython team.

Software guy, working in the applications team.

starlight.ai wrote: ↑

Fri Sep 12, 2025 1:48 pm

==> MP3 audio decoding on Pico should be possible with native hardware and MicroPython, but something somewhere is not supported

It's that no-one has developed it. Not enough interest. CircuitPython tends to focus on multimedia projects. They have a small team of paid developers to take it where Adafruit wants it to go. MicroPython? It's pretty much Damien's interests, plus whatever the sponsors pay for.

CircuitPython's MP3 playback is extremely limited (as described in the CircuitPython-Compatible MP3 Files section of the tutorial):

• bit rate less than 64kbit/s (aka potato quality)
• sample rates from 8kHz to 24kHz (the sort of thing we'd call MP2 files)
• PWM output only (which is okay for your PAM8302, but rules out I2S)

Any interrupts during playback (like you get lots of from the network hardware) distort playback, too.

It's going to be a stretch on an RP2040, and no-one's gone there yet. An RP2350 could likely run something based on Adafruit_MP3 (itself based on Helix Player), but even it has limited file compatibility.

For now, it's MP3 player modules, alas.

‘Remember the Golden Rule of Selling: "Do not resort to violence."’ — McGlashan.
Pronouns: he/him

starlight.ai wrote: ↑

Fri Sep 12, 2025 1:48 pm

In short:
==> WAV audio on Pico without additional hardware is solved, though challenging, through software
==> MP3 audio decoding on Pico should be possible with native hardware and MicroPython, but something somewhere is not supported

What is an engineer to do?

Same as always - Implement it yourself, convince someone to implement it for you, choose some alternative solution, or go without.

At least for MP3 playback there are alternatives; using add-on hardware, using CircuitPython if it suits your needs, or choosing a different product which does support what you need, for example a Pi SBC.

There may also be projects which implement MP3 playing in C on a Pico which could be ported to MicroPython. A quick search turned up this - https://github.com/ikjordan/picomp3lib - and there may be others, plus there is the implementation Adafruit has produced for CircuitPython.

You could also throw money at MicroPython to get them to implement it - https://github.com/sponsors/micropython - or pay for development yourself.

As much as I would also like to see MP3 playback as part of MicroPython my pragmatic solution, if I needed it, would be to use a Pi SBC. A Pi Zero 2W is just 15ドル and has everything one needs; all the software, memory, a SoC which can handle it, SD Card interface, and wireless connectivity. It supports audio output via HDMI, USB, Bluetooth, a HAT, and even analogue via GPIO.

In short; I would stand on the shoulders of giants who have already delivered, rather than wait for new heroes to come along, and that's far easier than undertaking the effort needed to earn myself accolades.

I think both of you (@hippy and @scruss) hit the nail and supplied the correct answers. It is true that WAV provides an operative solution and that the CircuitPython MP3 solution is very limited in its quality to near proof-of-concept inception and develops where AdaFruit wants to take the package. It is true that MicroPython is underfunded and that Pico Zero 2W (already at 15ドル) is rapidly replacing the market of utility for the Pico, and with full Ubuntu support simply provides operating system solutions. Seeing its price drop from 28ドル to 15ドル is really the changing moment.

To add a context, and close out this ticket: standard off-the-shelf webcams have this odd industry-wide quirk where sending audio across the local area network to the endpoints is not possible, and requires a ping to the manufacturer proprietary cloud on the global area network. This is assuredly not universe but in my experience was repeated over and over again, and manufacturers who blurred the lines of their terms of service to allow read-access to the webcam audio and video across the local area network drew a hard line on sending audio without the manufacturer global authentication. I had wanted to baseline Pico as the endpoint for area networks which could interact with the user through audio, at least outbound, such as processing state, but with Pico comparatively priced to Zero 2W (with SD cards raising the total to 20ドル) the operating system overhead of maintaining two systems is increasingly outdated, perhaps. ESP32 boards are cheaper.

Thanks for answering.

more AI word salad

‘Remember the Golden Rule of Selling: "Do not resort to violence."’ — McGlashan.
Pronouns: he/him

scruss wrote: ↑

Tue Sep 16, 2025 5:56 pm

more AI word salad

Username check out.

Although, ironically, AI checking tools say it's not AI.

Oh no, not again.

Yeai or nayai, the stench is genuine, my BS-meter is smoking, so I asked AnoI:

A fire alarm was triggered by what you're calling a "BS-meter," but this is a misunderstanding of how smoke alarms work, as they are designed to detect actual smoke, steam, dust, or chemical particles in the air, not metaphorical "bullshit". If your alarm is sounding, open windows to air out the room and check for actual sources of smoke like burning food or chemicals to ensure there isn't a real fire. If there is no visible smoke or fire, you may have a false alarm caused by high humidity, dust, or a malfunction.

I am lost, it must be aliens.

I have no idea what any of you are speaking about re: fire alarms and word salads; perhaps a user wrote a message and deleted after you commented? Neither of you responded to my hanging chad of ESP32, and my work on audio has little to do with supporting fire detection.

Thank you for your answers, and I consider the topic closed.

I have unsubscribed from the topic.
As it appears that only a moderate can restrict replies.