Inspired to write for all the wrong reasons
I guess it is time for my traditional “once every few years” blog post.
So, naturally, rather than returning with something sensible and manageable, I have decided to discuss Linux audio, neurological learning pathways, music games, PipeWire, neural amp modelling, disappearing Chromium ports, several USB interfaces and one elderly Behringer device that attempted to cremate itself on my desk.
Completely on brand, then.
If you just want to get Fee[dB]ack working go here
Welcome to Linux, Glenn! 😂
This particular rabbit hole started when I watched https://youtu.be/OqqPP7SwGcU?si=QxnyGvTe9cYG0nSu.
Welcome to Linux, Glenn!
Yes, Linux audio has historically been a royal clusterfuck.
To be fair, however, Glenn has invested years getting his Windows systems, software and hardware working exactly the way he wants. Moving to another operating system and expecting an entire professional studio built around proprietary hardware to behave identically was always going to be optimistic.
The interesting thing is that, while I was furiously typing a comment explaining that Linux was not really the problem, he arrived at roughly the same conclusion himself:
The problem is not that Linux does not support the hardware. The problem is that hardware manufacturers do not support Linux.
That distinction matters.
When I started doing audio stuff on Linux, free software was one of the few alternatives to piracy for someone with no money. It was an unbelievable pain in the arse, but I was not a professional, so I could afford to spend three days configuring something that would have taken twenty minutes on Windows.
Today, you do not need Linux to make music cheaply. There are excellent free and inexpensive applications everywhere.
Linux still offers something important, though: ownership, transparency and the possibility of keeping a functioning system alive after a manufacturer has decided that your perfectly good hardware is obsolete.
Freedom is the escape hatch.
Unfortunately, freedom is not nearly as comfortable as the brochure makes it look.
A brief history of Linux audio, or why we drink
The old Linux audio stack made a horrible sort of sense.
ALSA handled drivers and low-level access to the hardware.
PulseAudio handled ordinary desktop sound, frequently in an unholy latency-plagued mess.
JACK was the professional audio pony. It could take control of your interface, connect applications together and provide genuinely useful low-latency performance.
The slight drawback was that nothing talked nicely to anything else.
Starting JACK could make your desktop audio disappear. Changing interface might require rewriting configuration files. If an application grabbed the wrong device, the solution frequently involved killing several services and restarting them in a specific order while muttering ancient incantations.
If you wanted particularly low latency, you installed or compiled a suitably configured kernel, set real-time permissions and hoped you had not accidentally created a machine capable of locking itself solid at the exact moment you pressed Record.
It worked.
I produced things with it.
I cannot honestly say I always understood why.
Then PipeWire appeared.
PipeWire effectively gives desktop and professional audio a shared graph, while providing compatibility with the worlds that previously expected PulseAudio, JACK or ALSA. In principle, that is the solution we spent years asking for.
In practice, if you learnt Linux audio the old way, PipeWire behaves just differently enough to make you think you have suffered a minor brain injury.
PipeWire can operate the graph at a common rate and quantum, resampling streams when necessary. Its runtime settings include clock.force-rate and clock.force-quantum, which temporarily force the graph to a particular sample rate and processing quantum. Setting either back to zero releases the override.
This is sensible engineering.
Unfortunately, sensible engineering does not feel sensible when you change a setting inside an application and PipeWire quietly decides that no, we are not doing that today.
Audio hardware support, except not really
Most class-compliant USB audio hardware works on Linux.
That is why a cheap interface can sometimes behave beautifully while a far more expensive device becomes an illuminated paperweight.
The basic audio streams may work, but proprietary routing software, internal mixers, firmware tools and DSP control panels often do not. When a manufacturer provides only Windows and macOS software and refuses to document its protocol, Linux developers are left reverse-engineering the thing in their spare time.
That is not Linux failing to recognise audio.
That is the manufacturer deciding who is allowed to use the hardware they purchased.
Even on Windows, low-latency audio requires knowledge of ASIO drivers, buffer sizes, sample rates and device routing. The big difference is that manufacturers normally provide those drivers.
So, if we want serious Linux audio support, we need to stop shouting exclusively at Linux developers and start shouting at the companies selling us hardware.
Preferably before the hardware is discontinued.
Meanwhile, I still suck at guitar
I love music.
I have played guitar badly for years.
I have studied enough theory to understand fascinating things for approximately eleven minutes before they fall out of my head again.
This makes me the ideal target for music games.
I have played Rock Band 3, Rocksmith, BandFuse and now Fee[dB]ack because all of them offer the same seductive promise:
What if practising did not feel like practising?
The answer varies considerably depending on the game.
Rock Band 3 and the almost-real guitar
Rock Band 3 remains one of the greatest party games ever made. Its Pro instruments were also spectacularly ambitious.
The problem with Pro Guitar was not simply that MIDI guitar was niche.
The deeper problem was that it still was not the same as playing a real guitar.
The controller had strings and frets, and some of the coordination transferred, but the system was detecting the instrument as a controller rather than listening to a normal guitar signal. String vibration and noise could confuse detection, so I ended up dampening the strings in ways that had more to do with persuading the electronics than playing the instrument normally.
It occupied a peculiar halfway house.
It was infinitely closer to guitar than five coloured plastic buttons, but it was still a controller pretending to be an instrument.
Ambitious, clever and enormous fun.
Not quite guitar.
Rocksmith and the motorway through my brain
Rocksmith solved the obvious problem.
Plug in a real guitar.
Play real songs.
Fantastic.
The issue, at least for my particular collection of misfiring neurons, is the note highway.
It is brilliant at telling me exactly what to do now.
It is considerably less successful at making me remember what I just did.
I can follow a Rocksmith arrangement and experience the convincing sensation that I am playing it. Turn off the screen, however, and the entire thing can vanish as if somebody pulled the cartridge out of my brain.
This became more obvious when I compared it with Rock Band drums.
After playing Rock Band drums for several hours, I can strike the correct pad when the correct coloured rectangle reaches the bottom of the display. Take the screen away and ask me to maintain a basic four-on-the-floor groove autonomously, never mind a train beat, and everything becomes much less impressive.
The game has not necessarily taught me a piece of music.
It has trained me to respond to its stream of instructions.
Which leads to my completely unscientific theory:
Some music games do not teach you to play music. They play you.
The screen produces a stimulus.
I produce the requested movement.
Correct input. Correct output. Dopamine dispensed.
I am the peripheral.
When the display disappears, so does the external system that was supplying timing, sequence, anticipation and memory.
This is particularly significant for someone with AuDHD and working-memory issues. The highway becomes an external nervous system. It holds the next event for me, points to the correct action and continuously replaces information before I have to retain very much of it.
That is great for accessibility and immediate fun.
It may be less useful for transfer.
I am deliberately saying may because I have not found research directly proving that one commercial guitar game produces better learning than another. My experience is anecdotal, my brain is my brain, and a coloured motorway is not automatically bad pedagogy.
There is, however, interesting research around music reading.
Reading notation requires a musician to extract visual information while preparing future actions. A recent theoretical model describes this as “bi-temporal” processing: acting in the present while predicting what must be performed next. The research also connects notation reading with auditory-motor integration, memory, sensorimotor coupling and the gradual development of automatic execution.
That is more complicated than “Rocksmith uses fewer neural pathways”, which is the sort of phrase that sounds wonderfully scientific until an actual neuroscientist throws something at you.
A better description of what I think is happening is this:
Some interfaces emphasise immediate stimulus-response performance. Others encourage translation, prediction, chunking, recall and transfer.
Why BandFuse worked better for me
BandFuse was not perfect and did not survive commercially, but its animated tablature made more sense to my brain.
Instead of merely intercepting approaching objects, I had to interpret a representation of the music and convert it into a movement.
That additional step was harder.
It was also useful.
BandFuse’s practice tools could make you play a passage faster than the original. Once you returned to normal speed, the song suddenly seemed almost civilised.
Rock Band 3 Pro Guitar and BandFuse both felt closer to animated notation than a reaction highway. I had to look ahead, recognise shapes and relate what I saw to positions on the instrument.
Some of it remained after the screen went dark.
This does not mean animated tablature is universally superior. Standard notation, tablature, piano rolls and highways all represent different compromises. Research into sight-reading shows that visual patterns can become associated with motor actions, and even incidental exposure can produce learning of note-position-to-key-response relationships.
The interesting question is not which display is objectively best.
It is:
What does each display ask the brain to do, and does that activity survive once the display is removed?
Why I am madly in love with Fee[dB]ack
This is why Fee[dB]ack interests me.
Not because it has already solved the problem.
Because it might be allowed to explore it.
Commercial games eventually have to optimise for accessibility, retention, licensing and selling subscriptions. An open and community-led project can experiment with things that do not necessarily fit neatly into a product manager’s quarterly objectives.
Could Fee[dB]ack provide a friendly highway initially, then gradually remove prompts?
Could it alternate between the highway and animated tab?
Could it blank the display and test whether the player can recover the phrase from memory?
Could practice move between reading, hearing, imitation and recall?
Could it identify that someone repeatedly succeeds while the notes are visible but fails as soon as the visual prompt disappears?
Could it teach the structure of the music rather than simply delivering the next instruction?
For neurologically non-standard, distractible and working-memory-impaired idiots like me, that could be genuinely transformative.
And fun.
Fun is important.
People regularly design educational software that is theoretically excellent but feels like filling out a tax return while somebody plays a metronome at you.
Fee[dB]ack has the possibility of being both a game and a laboratory for different ways of learning music.
Provided, naturally, that you can get the bastard to make a noise.
So I tried Fee[dB]ack on Linux
This was where the adventure escalated.
I tested:
- Behringer UMC204HD
- NUX Mighty Air
- NUX MG-30
- Zoom G3X
- Valeton GP-5
- Rocksmith cable
- BandFuse cable
- one formerly living Behringer UCG-102
The encouraging result is that nearly everything worked on Linux.
The less encouraging result is that nearly everything worked differently.
USB input was generally possible. Note detection was generally possible. Audio output was generally possible.
Achieving all three simultaneously through the device I actually wanted was considerably more entertaining.
Fee[dB]ack is two audio systems in a trench coat
This is the critical thing I initially failed to understand.
Fee[dB]ack is obviously optimised around the simplest use case:
- Plug in one guitar cable.
- Select it.
- Play.
Anything more complicated requires planning because Fee[dB]ack does not really have one audio route.
It has two separate audio paths.
The user interface and backing-track playback live on the Chromium/Electron side of the application.
The guitar input, detection, monitoring and effects chain live in the native JUCE audio engine. The published desktop architecture describes an Electron application with a Chromium renderer and a separate C++/JUCE engine for low-latency audio I/O, VST hosting and real-time DSP. The project also advertises VST hosting, NAM amp modelling and low-latency audio I/O.
In simplified form:
BACKING TRACKChromium/Electron↓PipeWire playback ↓Audio output
Meanwhile:
GUITAR Interface capture ↓JUCE ↓Note detection ↓VST / NAM / cabinet IR ↓JUCE playback ↓Audio output
These paths can use the same device.
They do not have to.
That is the source of much of the apparent insanity.
Move the Chromium output and you move the song, but not necessarily the guitar.
Change the JUCE device and you may move guitar detection and processing without moving the song.
Route the interface input correctly and note detection may work perfectly, while the processed guitar is being sent somewhere else or is muted inside the monitoring chain.
The result is the classic Fee[dB]ack experience:
- the song is playing;
- the game detects notes;
- every setting looks plausible;
- the guitar is completely silent;
- the sound is inexplicably coming from the default sound card.
Nothing is necessarily broken.
You have successfully configured two independent audio systems to disagree with one another.
Progress!
The interface gauntlet
Behringer UMC204HD
The UMC204HD is class compliant, so capture appeared and worked.
Direct monitoring worked.
Fee[dB]ack detected the guitar.
The game audio, however, remained devoted to the integrated sound card until I manually rerouted the Chromium playback ports.
Once I understood the split architecture, this finally made sense. Chromium had selected the normal desktop default, while JUCE was dealing with the guitar independently.
NUX Mighty Air
The Mighty Air was useful because I could provide a dry guitar signal for clean detection.
Depending on the configuration, I could get USB guitar input or game playback behaving correctly, but persuading both paths to share the intended device exposed sample-rate disagreements and routing assumptions.
Zoom G3X
The Zoom worked, but with wonderfully inconsistent behaviour.
Configure the audio page.
Load a song.
No detection.
Restart Fee[dB]ack.
Detection suddenly works.
Why?
Because computers can smell fear.
NUX MG-30
The MG-30 also worked as an input.
Again, routing the Chromium output to the NUX did not automatically move the processed guitar signal. Changing settings could also leave the Fee[dB]ack audio page unresponsive or produce a song that loaded but refused to begin.
The most consistently successful arrangement remained:
USB device for guitar inputIntegrated card for game output
Which worked, but was not what I wanted.
Valeton GP-5
The GP-5 operates at 44.1 kHz in my setup, so it required the PipeWire graph to be treated accordingly.
I eventually got guitar travel in and out through the Valeton while the game audio went elsewhere.
Also, I spent half an hour convinced that the GP-5 was broken before discovering that I had used a USB-C cable which carried power but not data.
I hate USB-C cables.
Not the connector.
The mystery.
Every USB-C cable looks like every other USB-C cable, yet one carries video, high-speed data and enough power to run a small village, while another is apparently two wires and a lie.
Rocksmith and BandFuse cables
Both cables appeared under Linux and could be used for capture.
They were not ideal low-latency interfaces in my tests, but they did function, which is encouraging for anyone wanting the cheapest possible route into the game.
A Viking funeral for the UCG-102
Sadly, one veteran did not survive testing.
My ancient Behringer UCG-102.
I plugged it in.
Nothing appeared in lsusb.
Nothing appeared in arecord -l.
Then it became warm.
Then it became considerably warmer.
Then came the unmistakable smell which means an electrical component has decided to become an incense burner.
I unplugged it before it could complete the Viking funeral it had apparently planned for itself.
Farewell, cheap and cheerful old friend.
You nearly went to Valhalla.
You also nearly set fire to my desk.
Making the bloody thing work: UMC204HD edition
This is the recipe that finally gave me a stable and understandable setup.
Node names may differ slightly depending on your distribution, PipeWire configuration and application build.
1. Start qpwgraph
Launch the patchbay first so you can watch the devices and application ports appear:
qpwgraph &
Do this before Fee[dB]ack because watching the graph change is considerably more informative than repeatedly reopening an audio-settings page and swearing at it.
2. Force the PipeWire quantum and sample rate
For the UMC204HD:
pw-metadata -n settings 0 clock.force-quantum 128pw-metadata -n settings 0 clock.force-rate 48000
PipeWire documents clock.force-rate and clock.force-quantum as temporary runtime overrides for the graph.
At 48 kHz, a 128-sample buffer represents approximately 2.67 milliseconds per period.
That is not the total latency.
Input buffering, output buffering, converters, game processing, note detection, DSP and any additional internal queues all contribute to the total trip through the system.
For the Valeton GP-5, I instead used:
pw-metadata -n settings 0 clock.force-rate 44100``
Match the graph to the hardware before JUCE initialises. Otherwise, troubleshooting becomes an exciting mixture of resampling, silent ports and uncertainty about which subsystem ignored you.
3. Launch Fee[dB]ack through PipeWire’s JACK layer
From the directory containing the executable:
pw-jack ./feedback-desktop``
This allows the JUCE side to appear through PipeWire’s JACK compatibility environment rather than attempting to obtain the hardware through a conflicting raw path.
4. Route the guitar into JUCE
In qpwgraph, connect:
UMC204HD Capture 1 → slopsmith:in_1
This is the dry guitar input used by the native audio side for detection and processing.
5. Route the processed guitar back to the UMC204HD
Connect:
slopsmith:out_1 → UMC204HD Playback 1slopsmith:out_1 → UMC204HD Playback 2
This is the portion people easily miss.
Getting guitar into Fee[dB]ack does not guarantee that the monitored, processed guitar is returning to the interface you are listening to.
Detection and monitoring are related, but they are not the same thing.
6. Route the backing track separately
Start a song and look for the Chromium output ports.
Connect:
Chromium:out_FL → UMC204HD Playback 1Chromium:out_FR → UMC204HD Playback 2
Chromium is carrying the backing track and other browser-side playback.
JUCE is carrying the guitar.
Both must reach the UMC204HD.
7. Catch the disappearing Chromium bastard
There is one additional joy.
The Chromium playback ports may disappear when nothing is playing.
This means you can open qpwgraph, carefully examine the graph and conclude that the ports do not exist.
Start a song.
The ports appear.
Quickly connect them before they retreat into the undergrowth.
Then save the arrangement as a qpwgraph patchbay and activate it. qpwgraph’s patchbay can store connections and restore them when loaded; pinned connections are made persistent within the active patchbay configuration.
In qpwgraph:
- Start a song so the Chromium ports exist.
- Make the Chromium-to-UMC connections.
- Open the Patchbay menu.
- Save the patchbay.
- Activate it.
- Pin the required connections, or use Auto Pin while constructing the patchbay.
Now, when Chromium recreates its playback stream, qpwgraph has a fighting chance of reconnecting it to the correct outputs.
8. Check the physical UMC204HD controls
Before blaming PipeWire, check the interface itself:
- MONITOR A/B: out, for playback channels 1 and 2.
- MIX: fully clockwise toward PB.
- Confirm that the output and headphone levels are actually raised.
The MIX control matters because direct input monitoring can make you hear the dry analogue guitar even when the software return is completely broken.
That can create the opposite illusion:
“Great, the guitar is working!”
No.
The interface is allowing the guitar to bypass the computer while Fee[dB]ack silently screams into the void.
Turning toward PB lets you verify that you are hearing the processed software return rather than the direct analogue input.
9. Reset PipeWire afterward
When you finish:
pw-metadata -n settings 0 clock.force-quantum 0pw-metadata -n settings 0 clock.force-rate 0
This releases the forced settings. PipeWire’s documentation explicitly identifies zero as the value that allows the graph rate and quantum to vary again.
Do this now.
Otherwise, three weeks later, a completely unrelated application will behave strangely and you will have forgotten that Past You nailed the entire audio graph to 48 kHz and 128 samples.
Past You hates you and wants to see you suffer.
So where does this leave Linux audio?
Oddly optimistic.
PipeWire has not made Linux audio trivial. It has made something previously fragmented into a coherent graph, but coherent does not necessarily mean obvious.
The modern system is enormously capable.
It can connect desktop applications, professional audio software, USB devices and effects chains in ways that other operating systems often hide behind proprietary control panels.
It also lets you create an audio graph in which:
- the guitar reaches the detector;
- the detector confirms the notes;
- the effects chain processes the guitar;
- Chromium plays the backing track;
- every connection is technically functional;
- and absolutely none of it comes out of the headphones.
That is the Linux experience distilled into its purest form.
Fee[dB]ack itself is exciting precisely because it is not finished.
Its split architecture is currently awkward for more complex routing, but the same architecture gives it a proper native processing engine, plugin hosting, NAM support and the potential to develop beyond the limitations of earlier music games.
Most importantly, it could explore something those games only partially addressed:
How do we turn successful screen-following into music that remains in the hands, ears and brain after the screen goes dark?
I do not want only to become better at Fee[dB]ack.
I want Fee[dB]ack to help me become better without Fee[dB]ack.
If it can do that for people with distractibility, unusual learning patterns and working-memory limitations, while remaining a game rather than becoming fluorescent homework, it could become something genuinely special.
Until then, I will continue testing interfaces, chasing disappearing Chromium ports and wondering why the guitar is muted even though the game clearly knows I played the correct note.
At least I no longer need to sacrifice a goat to JACK.
Although I am keeping one nearby.
Just in case.
This post was created making extensive use of artificially stupid text generation, I apologise if the stupid doesn’t quite match that of the naturally challenged author. But I have no time, a life and still like bringing useful niche information to whoever may need it.
The Matt (il matto) 