Gmu Too

While I was working the recent burst of ziptuner updates I had some thoughts that perhaps I could do a similar refresh for the gmu build on the IZ2S zipit.  About 5 years ago I got a nifty client server setup going between my old record collection (converted to mp3 files on my PC) and the gmu player on the zipit.  Unfortunately, transforming the living room into a exercise room for the COV-ID lockdown kinda put the kabosh on all that.  Things got moved and I eventually lost track of the client server setup.  Back in the day that was pure http to the local server, so I imagined perhaps gmu could also use an update to https.  Why not leverage the same tiny-curl path as the ziptuner?

I quickly realized I could  also use an update to the theme choices with a font somewhere between huge and microscopic, so I could see a reasonable readable chunk of my playlist right in the gmu gui like I could in the old scripts.  Something like this.

  I can read this on the tiny zipit screen.

I consulted the Google AI to see what format was used for the font files. I sorta suspected SFont and the AI doubled down on that, but that's not quite it.  Meanwhile I examined the letters_large_white.png font file in mtpaint.  I divided the dimensions of the transparent png by the size of the large font letters in the theme.conf file, accounted for white space padding, and calculated 186 letters.  That skips the ASCII control chars and implements what looks like the Latin1 codepage.  It was actually a bit of a struggle do the resize math and get the characters in the right place in the bitmap to make display work.  The AI revealed it's quite bad at math but has an endless supply of sketchy ideas.  It got the list of letters wrong and rolled out several nifty chunks of code using SDL_ttf to generate new font files with that were never gonna work.

I did a quick and dirty rescale of the giant font file with imagemagick convert and tweaked the coordinates in the theme file and voila, we have a medium size theme. But all the letters were off by N and sliced up.  Oops.  I based my calculations on the outside dimensions of the letter boxes and the actual character dimensions came out something like 7.5 pixels wide instead of 7.  So I recalculated for real 7x10 characters and fudged the padding instead.  This time it worked.

Here's how it looks.  It's actually not terrible. 

Meanwhile there's some new stuff in the gmu github logs, including SDL_ttf font support.  What?  Why didn't the AI point that out while I was scrambling to resize the old bitmap font file.  I told it why I wanted to do that, and all of it's bad ideas used SDL_ttf fonts to generate bitmaps,  but it never connected the dots.  Anyhow, that's the right solution, but it only exists in the SDL2 branch of the gmu source code.  Gotta port that to the ancient SDL12 branch that I'm  currently working with.  Or... waitaminute, maybe I should build SDL2 for the zipit?  The AI helpfully suggested there's at least 2 different framebuffer backends now, when before there were none.  It enthusiastically provided a whole lotta suggestions, and went in circles several times over which choice was best until I finally had enough and called a halt.  Stash that idea for later. SDL12 with the blurry font was good enough for now.  The https support was top priority.  (You always gotta remember your priorities when AI cheerfully drags you off on another tangent)

I pulled out a copy of the old gmu-0.10.2-RC1 code and got busy.  It took several days to re-familiarize myself with all the build instructions and packaging tricks required to make it work on the zipit.  In 2021 I was using the Openwrt OS on the zipit OS and had to remember the completely different workarounds for the IZ2S build that I wanted this time.  I'd forgotten about the structural change to the config files around version 0.10 so I wasted a few days wondering why nothing worked.  But I got over the hump eventually and got some sound.  Then I assembled a test playlist with a sampling of sources, some http and some https, mostly mp3, but one flac, maybe an ogg stream, and even one in mono.  Not many of these would actually play in the baseline build.  Maybe just one.

 

To be continued... 

Ziptuner v1.4

I previously said I'd have to get back to the ffmpeg for IZ2S later...  

So after I finally completed ziptuner v1.3 I did just that.  I suspect ffmpeg is gonna be a long term effort to get it to do everything I want, but at least it seems possible.  To get it started I leveraged the google search AI to help assemble a minimal configuration of mbedTLS v3.6.4, which I eventually used to build v3.6.6 despite their move to CMAKE.  Perhaps for the next round I'll try to leverage this again for a v4 build.  But once again, that's on the back burner til later.  I wound up dropping TLS 1.3 from the config for now, so it's about the same functionally as bearssl.  But it looks like mbedTLS has a future and since it's also used by tiny-curl and openwrt, so that works for me.

I added mbedTLS into the ffmpeg config mix and ran off a new build capable of running some internet radio streams.  I initially started with ffmpeg v4.4 but had some trouble compiling the channel layout code.  I forget the details, but I probably should revisit this someday.  Meanwhile the AI suggested a switch to ffmpeg v4.1 and it seemed to work. After a couple rounds of adding/subtracting components it weighs in at just under 2M (plus some external codecs like libopus).  That's pretty reasonable on the zipit so I moved into test mode. 

I tested it on a couple dozen stations and tweaked the ziptuner wrapper script to pull in the ffmpeg format for ICY metadata StreamTitle update notifications with a single filter for both mpg123 and ffmpeg.  Looks pretty good. 

The AI got really enthusiastic at this point and started suggesting all sorts of enhancements for everything, but within the nonsense were the kernels of some decent ideas that I helped it refine with a few follow up prompts.  I had to keep reminding it to keep the focus on "simple" solutions and resist the urge to over-engineer things.  I really like the way we isolated the tail | sed log file filter pipeline from the -mp3 and -p PLAY button pipelines in the IZ2S ziptuner.sh wrapper script.

At this point the ffmpeg engine could connect to most of the internet radio stations, but the opus and ogg streams seemed to be struggling.  I figured ffmpeg was probably not using the fixed point decoders.  Getting that debugged on internet streams in ffmpeg was a bit of a challenge so I backed off a little and built ogg123 instead since it seemed easier to debug with music files on the SD card.  Once I got ogg and opus running smoothly there I went back to work on ffmpeg.  After some back and forth with the AI, we eventually settled on some confusing tweaks to the configure settings, and then some hacking on ffmpeg sources.  But after all that I finally got it pulled in and working with the fixed point decoders only.

I was hoping to go with an ffmpeg only system but unfortunately ffmpeg with mbedTLS fails to complete the TLS handshake negotiation with a few stations that mpg123 with curl and bearssl handles just fine.  Oh well.  At least the dual mpg123 and ffmpeg setup is viable. While testing the dual player setup I noticed some stations were spamming stream title updates every second or so so I  patched mpg123 to only print the first update for each song change.  I also learned running mpg123 with script disrupts dialog input unless I feed it from </dev/null, so I fixed that as well.

All the testing gave me some ideas for some simple but effective ziptuner improvements, so I coded them up.  Now when the -l logfile option is used it automatically bring up the log viewer screen whenever you start to PLAY a station.  This was handy for debugging the song title filter pipeline but I decided I just like it for normal use as well.  I also added some -x,y,z command options to launch external commands from ziptuner main menu for easy access to handy things like the mixer.   

Now  I can tweak the volume in rexima without exiting the ziptuner.

At this point, with the AI onboard, I finally felt like I might be able to tackle the zombie problem on IZ2S.  I grilled it with questions, hints, and suggestions and and finally forced a few answers out of it that seemed to help.  It looks like the ancient busybox init on initial ramdisk in the stock 2.6.21.1 kernel is so old that it only reaps zombies from programs run in inittab.  Any normal init process will reap the orphaned zombies and keep the process table clean.  That finally explains why the zombies are so annoying on IZ2S.

I also learned all sorts of details about what sorta process tree I get with different approaches to run the player programs, and how to view it through the /proc filesyste.  Using system() to run the STOP command was guaranteed to create a zombie since it blocks the SIGCHLD sygnal, which thwarts any sorta waitpid trap in the ziptuner.  I fixed this, and pruned the process tree to get ffmpeg situated as a direct child of ziptuner and voila, no zombies on IZ2S with the ffmpeg player pipeline.

At this point I decided it was time for a ziptuner v1.4 release.

I still need to hack ffmpeg some more to get song title updates from aac and ogg/opus streams, and also figure out how to fix the tls handshake so I can drop the double player on IZ2S.

Update June 3, 2026

Wouldn't you know it...  As I was cleaning up all my messy AI browser tabs, I had some final thoughts about ffmpeg 4.4.  I happened to have an Ubuntu build of 4.4.2 on a PC so I tried it on one of the stations that was giving me trouble with my zipit build.  It worked.  I checked the build configuration and it listed --enable-gnutls.  This got me thinking, maybe I oughta try one of the full TLS implementations on the zipit after all, but first I asked the AI again if there was an openssl wrapper for bearssl.  Why not?  It must've seen my mouse hovering over the gnutls because this time it mentioned the libtls_bearssl wrapper right after it pronounced bearssl was functionally incapable of emulating openssl.  So I asked the AI if I could build ffmpeg with it.  Sure thing, it drops right in with --enable-libtls.  Say what?  Did it enjoy watching me struggle?

I fetched libtls_bearssl from github and built it for the IZ2S zipit.  I had to tweak the Makefile to remove some warning flags unbeknownst to the ancient compiler, and I reverted some file opens with O_CLOEXEC to the somewhat racy code used before that flag was invented.  Otherwise the build went smooth.  It's only about 60K of shim around the smallish bearssl shared library.  Not too shabby!  Next I reconfigured my patched up ffmpeg code base with the --enable-libtls option instead of --enable-mbedtls and it rebuilt (and worked) without a hitch.  No more TLS handshake issues.

I asked the AI what would it recommend for the future when TLS 1.2 is declared obsolete and it said wolfSSL was the way to go for TLS 1.3.  Apparently tiny-curl is developed by the wolfSSL team and openwrt still supports wolfSSL despite selecting mbedTLS as the default.  Ok, I'll keep that in mind when that time comes -- if the zipits make it that far into the future.  Some of the tacky plastic on them is starting to get sticky.  That's a bit of a bad omen.

I added a lean ffmpeg/bearssl version of the ziptuner v1.4 package as v1.4.1.