HLS Radio Converter turns a Raspberry Pi into the MP3 translator old Frontier Silicon Wi-Fi radios need

A Wi-Fi radio can power on, find the network and still play nothing from a station that streams in HLS. Clifford Farrugia’s HLS Radio Converter is for radios “based on Frontier Silicon that understand audio/mpeg but not HLS,” according to its README. HLS is the streaming format that chops audio into chunks listed in an .m3u8 playlist. These radios want one continuous MP3 stream instead.

So the Pi does the translating. You take the station’s .m3u8 address, percent-encode it onto the end of the Pi’s address, and type that into the radio. “There is nothing to configure,” the README says: no station list, no playlist file, nothing to edit on the Pi. Behind that URL, FFmpeg re-encodes the station to 192 kbit/s MP3, because “Nearly every station is AAC, which has to be re-encoded to MP3, and only FFmpeg does that.”

The cost is CPU, and the README measures it. On a Raspberry Pi 3, one 192 kbit/s station takes “~165% of one core” and about 100 MB of RAM, so a Pi 3 handles “about two different 192 kbit/s stations.” Six radios on the same station cost nothing extra, because the server runs one pipeline per station and shares it. “Ten radios on one station costs one decode, not ten,” the README says.

The microwave part is real. Version 2.3.0 added a repair for radios that fell into garbled audio and stayed there “until the service was restarted,” according to the changelog. Farrugia measured his own server during the fault and found it clean: “no gaps in the TCP byte stream across 39 connections over 3.5 hours, an unbroken chain of 32 355 MP3 frames.” The problem was inside the radio, whose MP3 decoder “gives up on damaged audio and never recovers on its own.”

Wi-Fi interference doesn’t drop the audio. TCP resends the damaged packets, the radio gets them late, and the server’s own timing sees nothing. The kernel does see it: the changelog counts “47 retransmissions in 776 s on a healthy connection” against “21 inside a single ten-second window during interference.” So now a burst of retransmissions makes the server hang up on the radio on purpose, and the radio reconnects with a fresh decoder. With the oven at full power, the audio “glitches for as long as the interference lasts and is clean immediately after, with no manual restart.”

Getting there took a few tries. “Four microwave tests. Each of the first three found a bug, and the last one passed,” the 2.3.1 notes say. Then 2.3.2 caught one more: a two-minute timer that disconnected “every listener of every station” whether anything was wrong or not. The changelog quotes what was heard on the real radio, verbatim: “every 2 minutes, I’m noticing the radio either skipping a few seconds, or repeating a few seconds.” The timer is now off by default.

The repository dates to August 2021, and the contributing guide keeps a section on “Why version 1 wedged after a few days”: a single file with three threads, where “One unresponsive CDN connection hung the stream forever” and a wedged stream “stayed wedged until reboot.” Version 2.0.0 shipped on October 17, 2026, and the changelog lists 13 versions through 2.3.2 on October 22. Docker “was considered and deliberately left out,” the guide says, because on Pi-class hardware it costs RAM and a second copy of FFmpeg.

Expect more of this. Every streaming format change leaves a pile of working hardware behind it, and a small box that converts the new thing back into the old thing keeps it out of the junk drawer. The open question for this one sits in its own changelog: a decoder that wedges with no evidence at all still waits for the radio to reconnect on its own, which Farrugia measured at every 20 to 60 seconds.

The microwave is in the contributing guide now.