Using Pipewire to Make A Music Synthesizer

Illustration from Project Gutenberg's The Tenniel Illustrations for Carroll's Alice in Wonderland by Sir John Tenniel.

Thinking about the linux desktop audio problem:

I'm not the only one who finds this weird: https://t.co/b2BZMiak07

— eternal Doorman (@IanANGrant66) May 17, 2025

 I noticed that if you change the volume using the Gnome volume keys it changes it in jumps. Usually you don't notice, but if you play a pure sine tone then you can easily hear the distortion. If you want to play with pipewire from C on Ubuntu 24.04 then it's really easy. The pipewire tutorials and examples can be compiled and run if you just first install the pipewire-0.3-dev package with

sudo apt install libpipewire-0.3-dev

But the API is sooo far away from pluggable, typed streams that I find it quite depressing. Is it because nobody understands the necessary type system. See  Programming Channel Processes and Alice's Adventures In The Wonderland Wide Web. [Update: you have to understand the WirePlumber API too]. It's a problem for people who rely on screen-readers, see I Want to Love Linux. It Doesn’t Love Me Back: Post 2 – The Audio Stack Is a Crime Scene.

And there's a bootstrap problem too. Only 10% of blind people can read Braille, and that's mainly due to the fact that Braille displays are so expensive, because with a small computer with an audio output (that works!) and a Braille display people would be able to learn very quickly. See Electromechanical Refreshable Braille Module, Hands-Free Haptic Braille Display Is Making Waves and Refreshable Braille Display.

 

Subscribe to Brodie Robertson. 

There are tools that focus on programmable user-interfaces, but they are specialised to certain things like menus and are based on janky languages:

Subscribe to Bread on Penguins.

For accessibility you have to have completely programmable user-interfaces,  but there is no such thing because though the languages to do this exist, nobody who is involved in producing the software actually knows anything about them.

There are people around who can think about this stuff, and who can actually write compilers too. Clifford Click has a Coffee Compiler Club going:

That paper by Lemerre is SSA Translation is an Abstract Interpretation. But I am not really interested in compilers to compile garbage code, I am more interested in formalisms that let people compose programs together in natural ways that fit the kinds of things they want machines to do. I think if you know in detail how the programs are being composed then you will be able to easily write efficient just-in-time compilers. See  Nir Lichtman's 12-minute Linux Distribution Video and On Web Sites for LETS Schemes and DAOs.

To get back to the subject of this post: you plug a USB CD-Reader into your computer and insert an audio CD, then a window pops up which looks a bit like the display and buttons you would see on a CD-player of the kind that were popular in the eighties:

Then you click on the buttons and it plays the tracks you select. But the actual program that runs was composed by plugging together a system where buttons were connected with controls which select the track and position, or the volume, and events occurring during playback are connected to display elements which are a sequences of frames made up from image-generating functions. One of those might be a representation of an audio spectrum from a DFT module inserted as a filter in the stream of data from the CD via the USB interface to the system's audio output. But all of the code do that was composed together on the fly in response to the original event when the audio CD was inserted into the player. The particular modules that were plugged together were specified by the user in some sort of CAD program which itself was built from components for displaying menus and responding to pointer selections on a display, and that program too was composed in the same way. Exactly how the user did this is immaterial, what matters is just the formal characteristics of the modules that were plugged together: their actual concrete implementation could have been commands typed into a terminal interface, or via a compiler which took a symbolic formal description as input in some syntactic structure designed in the same way, but in the end these different concrete representations are all essentially the same formal system.  That's how I think things should work. I'm not the only one: see  Eron Woolf on Why Open Source is Failing. But it seems in theory we're still hung up on representation: see Jenann Ismael - Laplace meets Godel: How Self reference Foils Prediction. I think that if instead we focus on process then things will be much more sensible!

Subscribe to Cliff Click.