Fedora 43 is out
The thumbnail at the left shows a brand new installation of Fedora 43 Workstation running Giocoso in perfect fashion (and with no weird lack-of-graphics problems!).
I dislike the Fedora installation process: it assumes answers to questions it never prompts you for and it's harder than it should be to over-ride those assumptions. For example, no power on Earth would ever persuade me to use the btrfs file system as my main file system but it's Fedora's default option for the root partition. Finding how to change things to use ext4 instead is much harder than it should be, requiring you to click on various unidentified sets of three dots (I believe the yoof call them 'hamburger menus') and then do an awful lot of manual finagling. Not my recommended operating system, then… but at least my software runs on it without drama!
Giocoso Broken!
Click on the thumbnail to this post and see if you can see a bit of a problem!
In one window, on the left, you see Giocoso running as it's supposed to: displaying album art within its terminal session. In the window on the right, however, you see Giocoso playing music just fine… but there's no album art on display.
Giocoso has always displayed its album art by using a technology called “sixel graphics”. Terminals that support sixel graphics can display an image within the terminal by using a command such as: img2sixel albumart.jpg. Konsole, the KDE terminal I'm using on the right of that thumbnail has always supported doing this, which is just as well as it's the terminal I use daily to develop Giocoso in the first place! Unfortunately, as that screenshot tells you, Konsole has stopped doing this for mysterious reasons that I can't fathom. It now means that Giocoso run on any version of KDE within a Konsole window is at risk of not being able to display album art graphics sometime in the near future. The specific version of Konsole that appears to have developed this problem is version 25.08.2.
Since my desktop PC runs on EndeavourOS (a bleeding-edge distro based on Arch Linux), it's software stack is forever being updated: it's picked up the new version of Konsole and has lost the ability it once had to display in-terminal album art. My music playing PC (the one that's plugged into the amplifier and speakers) is running Debian 13, a much more sedate (some would call it old-fashioned!) distro that is running version 24ish of Konsole. Clearly, the Konsole developers nixed sixel graphics sometime in the last year: I'm not holding my breath for them to un-nix any time soon, sadly.
There are alternative terminal emulators, of course: xterm, for one. Unfortunately, they need to be compiled with sixel graphics support and none of the many terminals I've tried on EndeavourOS display sixel graphics properly:
That's xterm not displaying a JPG file. It's true for uxterm, too; for ghosty; for mintty; darktile, gnome-terminal and any other terminal emulator you might suggest, at least on EndeavourOS (and Arch or Arch-derived distros in general: I found Manjaro to be similarly affected).
The only exception is a terminal emulator called kitty, which doesn't use sixel graphics at all, but its own unique way of doing in-terminal graphics which continues to work in every environment I tested:
Unfortunately, you can see that kitty displaying anything requires some quite new syntax… and positioning the graphics display is nowhere near as easy to do as with sixel graphics. I'm also reluctant to make Giocoso dependent on a specific terminal emulator. So, this is not a road I'm keen to journey down.
Of course, Giocoso already has a workaround:
You've always been able to configure Giocoso to display the album art in its own separate pop-out window, which is nowhere near as elegant but continues to work fine, even on Arch-based distros:
For now, my understanding is that this is the only way to get album art displayed correctly on a fully-updated Arch-based distro. More worryingly, as other distros upgrade their KDE environments, I suspect they will lose the ability to do in-terminal graphics display, too. There's nothing much I can do about that, I'm afraid, though I am on a kitty learning curve as we speak.
Edited to add: I have swiftly realised that the kitty terminal emulator is just a special example of a terminal that understands the kitty graphics protocol. Other browsers can understand that protocol too, so it's easy (even on an Arch-based distro!) to get Konsole or other browsers to display images using it:
The title bar tells you this is Konsole… but it's still displaying a piece of albumart anyway! So this is definitely a route I will have to travel in the near future, I think!
With apologies...
I started this morning with an innocent desire to learn how to host two domain names from the one server (I know how to do it with Apache and Wordpress, but I'm not using that technology stack any more). One thing lead to another and by lunchtime, I had literally re-directed absolutelybaching.com to bbritten.com, even though bbritten.com is running on spare hardware that's as powerful as an asthmatic ant. Basically, I hadn't meant to switch the domains around, but ended up doing so anyway: my enthusiasm got the better of me!
There will be quite a few weeks before I finally bring over all the content I intend to transfer to the new site. I'm afraid things will look rather unfinished and rough-and-ready until that process is complete.
Got there, at last!
The screenshot at the left tells you that, after about 5 or 6 years of working towards it, I've finally achieved my goal of having listened to every recording in my collection, with Giocoso, at least once.
The last few recordings were dealt with much faster than I'd anticipated, in fact.
So what's next? Well, basically… to immediately screw up the statistics by adding a bunch of new recordings to which to listen! There's 758GB of ripped music sitting on my hard disk that needs classifying, cataloguing and adding to the collection. That's approximately 1,895 new CDs-worth of music. It will be added in small increments, though, with listening to the new additions being worked into randomised re-listening of existing music, so the 'percentage unplayed' should never rise significantly. (Famous last words!)
Progress on switching things over to bbritten.com continues, if not exactly at pace then at least with slow determination!
I also have to apologise to visitors again, today, for a network outage that made the site unavailable for around a couple of hours. Not my fault, this time, but my ISP's (though we don't yet know the details). That's the third outage since the end of August, one due to the network infrastructure, one due to a widespread network outage and now one due to an ISP's apparent inability to configure itself properly. Very annoying… but they each gave me more time to listen to music, so it's all good in the end, I guess!
Giocoso and Pipewire
The Linux audio stack is a convoluted mess!
In the beginning, Linux used OSS (the Open Sound System). This was replaced in the late 1990s by ALSA, the Advanced Linux Sound Architecture. ALSA is a kernel-level sound architecture that has no support for mixing multiple audio streams (so two programs cann't play simultaneously and one would block the other: some of us think this is what playing classical music ought to be like!) and no per-application volume control, because the kernel doesn't concern itself with the details as to what programs users might be running.
Along came PulseAudio, in the mid-2000s. It provided a wrapper around ALSA that allowed multiple programs to sound simultaneously and provided per-application volume control. It also added network audio streaming. By sitting on top of ALSA, however, PulseAudio added complexity to the sound stack and made working out why sound didn't work properly more complex, not less. It also was a high-latency layer, that made real-time audio tricky and started to fail, with jitter and dropouts, when the CPU was stressed enough.
So finally, in around 2015, PipeWire was invented. It replaces PulseAudio with a lower-latency and better real-time performance that's more immune to CPU load than PulseAudio ever was. PipeWire still sits on top of ALSA (ALSA is the kernel-level audio stuff, so both PulseAudio and PipeWire are the user-layer interface to ALSA). Amusingly, PipeWire runs a PulseAudio compatibility layer, so applications designed to run with PulseAudio can (allegedly) work seamlessly with PipeWire. I say 'amusingly' with venom because it now means you run an application and you haven't necessarily got a clue how it's talking to ALSA: it might be using the PulseAudio interface, or the PipeWire. Everything still works either way, so you're left a bit in the dark!
My music player PC (an ancient Mac Mini) runs Linux Mint. Linux Mint switched to using PipeWire as the default audio interface in the Wilma release (which is approximately late last year). I hadn't been aware of any of that… until I did a big software update the other day and things got “interesting”!
The issue is Giocoso's pause/resume functionality. Giocoso tells the process running the ffmpeg audio stream handler either to pause itself or resume itself. Under PulseAudio (or direct ALSA) doing this is not a problem: neither cared if the process was frozen or not, so resuming a frozen playback was without drama.
But PipeWire seeks to be modern and more efficient… which, of course, means it messes with the tried and true! When it detects that audio process has stalled, it suspends audio nodes to save power, marks the stream node as inactive and all its resources are freed. This poses a problem on playback resumption: the audio buffer behind the paused process will have been cleared, meaning that when the audio stream is resumed, it does so with invalid timestamps… and that manifests itself in garbled or 'scratchy' sound.
So guess what happened to my Giocoso setup after I foolishly subjected the Mac Mini in question to a recent software update? Pausing playback worked fine, but resuming it sounded like a Dalek with laryngitis had entered the room. Or maybe a Dalek attempting to sing Tristan und Isolde from the bottom of a swimming pool. It wasn't pleasant, put it that way.
Basically, the punchline is this: if your Linux distro uses PipeWire as its default audio stream handler, Giocoso's Pause/Resume is probably broken.
There is allegedly a fix. If you are able to tell PipeWire, “Do not treat a suspended audio device as being dead”, then the auto-cleanup of resources doesn't take place and the resumption of the playback should work as it used to. To do that, you need to create a new file:
~/.config/pipewire/pipewire.conf.d/99-nosuspend.conf
In that file, you type the following:
context.properties = {
suspend-timeout-seconds = 0
}
Finally, you re-start PipeWire to get the new setting picked up and applied:
systemctl --user restart pipewire
Once these textual fixes are in-place, you'll find that Giocoso pauses and resumes cleanly once more.
This will be a problem for many modern Linux distros, because they've all been switching over to PipeWire by default quietly in recent months. The same fix should apply to them all. A new release of Giocoso will eventually be produced that applies this fix automatically, if PipeWire is detected on your system… but for now, the fix has to be applied manually.
My apologies for any inconvenience: this is what happens when the technological rug is tugged from underneath one! Giocoso development is, frankly, just a question of keeping up with what other Linux developers are… er, breaking!
Update 1: It turns out that this “fix” doesn't really work very reliably. Fiddling with the PipeWire suspend timeout doesn't appear to have fixed the garbled sound problem if the music playback is paused for a very long time (such as overnight): the resumed playback still sounds awful in that case. I shall attempt to get Giocoso working on different hardware to see if that resolves the issue, though why hardware which worked fine at the beginning of the week suddenly decides to misbehave after a software update is a bit of a mystery!
Update 2: Well, after much fiddling with other hardware, I ended up issuing the following commands on the original PC:
systemctl --user --now disable pipewire pipewire-pulse wireplumber systemctl --user mask pipewire pipewire-pulse wireplumber
…to stop and disable pipewire. Then I issued this command:
sudo apt remove --purge pipewire pipewire-audio-client-libraries wireplumber
…to remove pipewire and PulseAudio from the Linux Mint 22 system completely. That means this PC is now going to be using ALSA directly (which Giocoso is happy doing). Finally, I issued this command:
sudo apt-mark hold pulseaudio pipewire
…to prevent Linux Mint “accidentally” re-installing either PulseAudio or PipeWire. A reboot followed at this point and, once the PC was back up, I issued the command:
aplay /usr/share/sounds/alsa/Front_Center.wav
…to directly play some sound… and heard everything just fine. The command:
aplay -l
…reassured me that the operating system could still see and enumerate audio devices correctly:
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: CS4208 Analog [CS4208 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]
Subdevices: 0/1
Subdevice #0: subdevice #0
I was thus able to configure Giocoso to use the “plughw:1,1” device (the digital, optical output) and music playback was fine. I then paused a piece of music in mid-play overnight. On waking, music playback was able to be resumed without any garbling or distortion.
The short take on this is, therefore, that Giocoso works fine with PipeWire so long as you don't pause or resume; that it works fine with PipeWire for short pauses and resumes if you set the suspend-timeout-seconds parameter; but that it does not work at all well with PipeWire if you intend to pause for lengthy periods (say, a half hour or more). My advice is therefore to run Giocoso on systems that do not have PipeWire installed at all (such as Alpine Linux); to remove it if it is installed; and to avoid even PulseAudio unless you intend to route Giocoso's playback over your home network. Use ALSA directly, as Giocoso was always intended to do, basically.
It is possible that I shall nevertheless re-write Giocoso's pause/resume functionality to avoid stopping and resuming audio playback at the per-process level. Giocoso already has a pause/resume functionality that involves launching a completely new playback process when music playback is resumed: the Giocoso Pro 'Global Resume' functionality. If that were employed as the sole pause/resume functionality, the garbled sound issue would be resolved even in the presence of PipeWire. It's a lot of work, however, and I wouldn't hold my breath!