FXRoute, browser-controlled Linux audio player and DSP control surface for mini PCs

[cobby]

Hi all,

I just open-sourced a project called FXRoute:

GitHub - CobbyCode/fxroute: Browser-controlled audio player and DSP control surface for Linux mini PCs, desktops, and dedicated audio machines.

Browser-controlled audio player and DSP control surface for Linux mini PCs, desktops, and dedicated audio machines. - CobbyCode/fxroute

github.com

I built it for a small Linux audio PC connected to a DAC / stereo setup, with control from phone, tablet, or laptop over the local network.

The main goal is to make a local Linux playback box much easier to set up and live with, especially when using PipeWire + EasyEffects for DSP.

What I wanted was a setup where you only really need:
- a reasonably current Linux distro with a modern PipeWire-based desktop audio stack
- FXRoute
- and your normal audio hardware

From there, the idea is that you can get to a usable and fairly serious DSP setup without having to assemble a whole stack by hand.

Current focus:
- browser control from any device on the LAN
- local playback, playlists, radio, and convenient library import
- EasyEffects preset switching
- A/B compare
- convolver / PEQ / REW-oriented workflows
- practical DRC use on a dedicated Linux audio machine
- Spotify desktop control on the host machine

Installation is intentionally straightforward. On a supported Linux system, it is basically: clone the repo, run ./install.sh, open the web UI, and start using it.

So far I have tested it on Ubuntu, Fedora, and openSUSE Tumbleweed, with a modern PipeWire-based setup.

If this sounds useful to anyone here, I’d be happy about feedback, especially from people using Linux audio PCs, EasyEffects, convolution, or room correction in a real stereo setup.

 

[cobby]

Some more pictures.

Library Import

The Import and PEQ part.

 

[john61ct]

LOVE the A/B function! Can that swap between whole sets of filters across lotsa channels, active crossovers, per-driver EQ, also change flow routing turn channels on / off ?

Raspberry Pi support??

Squeezelite / SqueezeDSP support?

 

[cobby]

LOVE the A/B function! Can that swap between whole sets of filters across lotsa channels, active crossovers, per-driver EQ, also change flow routing turn channels on / off ?

Raspberry Pi support??

Squeezelite / SqueezeDSP support?

Thanks a lot.

Yep, the A/B function swaps whole EasyEffects preset sets, not just individual filters.

Right now FXRoute is still very stereo-focused, so it does not yet target active crossovers, per-driver EQ, or channel routing on/off.

That said, I’d definitely be interested in pushing it further. One thing already on my roadmap is an A+B merge action, so you could combine two compare slots into one new preset — for example, convolver + PEQ.

Raspberry Pi is not a main target at the moment, and there are probably better tools for that use case. My focus so far has been more on typical Linux desktop / mini-PC setups.

There is no Squeezelite / SqueezeDSP support currently. FXRoute is more its own playback + DSP control stack than an LMS / Squeezebox frontend.

Give it a try — you might even have some old x86 hardware lying around in a corner that would be perfect for testing.

 

[somebodyelse]

From the description above I was expecting something headless, and wondering how that would work with EasyEffects. The README on the GitHub page makes it clear that this is not the case - it requires a desktop session.

 

[cobby]

From the description above I was expecting something headless, and wondering how that would work with EasyEffects. The README on the GitHub page makes it clear that this is not the case - it requires a desktop session.

Yes, that’s correct, it currently expects a normal Linux desktop session.

In practice though, it is much closer to a “headless-feeling” audio appliance than to a keyboard-and-monitor desktop workflow. The box can just sit there, auto-login, auto-start what it needs, and then be controlled from the browser over the local network.
The desktop session is mainly there because EasyEffects lives in that user session today, and Spotify control also targets the local desktop app.

So the session is still required under the hood, but in day-to-day use you usually do not interact with the desktop directly.

Also, EasyEffects does support socket based control now, so FXRoute is not driving it by poking at the GUI. It talks to the EasyEffects control socket (EasyEffectsServer), and EasyEffects can be started in `--gapplication-service` mode.
So it still behaves very much like a browser-controlled system, just not a true no-desktop setup.

Another upside is that I can just use a normal Linux desktop as the base. That makes setup much simpler, and it also lets me use the regular Spotify desktop app instead of relying on some separate third-party client.

 

[john61ct]

I'm putting off getting into using a "PC required fulltime" in my audio system(s), but if it proves necessary I do prefer Linux over windoze, and would try FXRoute then.

AFAIK RPI5 running Raspberry Pi OS (Bookworm) is no harder than supporting another distro, EasyEffects & PipeWire are baked in

but yes the processing power is a limitation, and ofc you set your own project priorities.

...


I am only looking at "passthrough standalone" convolving

separately from "software as renderer/player"

And the "ad-hoc user" tone controls / EQ, together with the volume control / loudness compensation

must be accessible from the MLP - will never have a computer there, except maybe an Android screen device "as remote"

Raspberry Pi is not a main target at the moment, and there are probably better tools for that use case. My focus so far has been more on typical Linux desktop / mini-PC setups.

 

[cobby]

I'm putting off getting into using PC required fulltime" in my audio system(s), but if it proves necessary I do prefer Linux over windoze, and would try FXRoute then.

AFAIK RPI5 running Raspberry Pi OS (Bookworm) is no harder than supporting another distro, EasyEffects & PipeWire are baked in

but yes the processing power is a limitation, and ofc you set your own project priorities.

...


I am only looking at "passthrough standalone" convolving

separately from "software as renderer/player"

And the "ad-hoc user" tone controls / EQ, together with the volume control / loudness compensation

must be accessible from the MLP - will never have a computer there, except maybe an Android screen device "as remote"

That makes sense, and I think that is a good distinction.

For convolver use, FXRoute does already have one thing that is very helpful there: when creating a convolver filter, it also uses the level-matched bypass filters (GSonic f.e.), which makes A/B comparison much more meaningful. So for listening comparisons, that part is already covered quite nicely.
Neutral is a flat filter preset, while Direct is the EE bypass, as pure you can get on a Linux.

That said, it is still software-side preset switching, not true hardware passthrough or a hardware bypass switch.

For the ad-hoc user controls from the MLP, that part is very much the idea: volume, loudness/headroom-style helpers, EQ/filters, preset switching, etc. should be usable without touching a computer directly, from anything with a browser, like a phone, tablet, or Android screen device.

On Raspberry Pi 5 / Bookworm: fair point, and I agree it is worth trying. PipeWire and EasyEffects being part of the normal stack there makes it much more plausible than older Pi setups.

I just have not validated Pi yet, and mini PCs happened to be the first target here. Right now they are often cheaper than a Pi once you include storage, sometimes even lower power in practice, and easy to run fanless/silent, so they were the more obvious path for me to focus on first.

 

[john61ct]

Sounds good.

I'm collecting parts for a big thirsty noisy NAS, collecting affordable old multichannel interfacii to try out convolving crossovers, timing delays / phase alignment tuning & speaker-level comp EQ in my learning curve.

But still doing much as possible OG analog to start with.

 

[somebodyelse]

I just have not validated Pi yet, and mini PCs happened to be the first target here. Right now they are often cheaper than a Pi once you include storage, sometimes even lower power in practice, and easy to run fanless/silent, so they were the more obvious path for me to focus on first.

Have you tried old thin clients for this? They're often much cheaper than a Pi, and usually fanless. My only reservation is how much memory and storage you need for a full GUI install compared to something minimal like daphile (headless, uses LMS and BruteFIR).

 

[cobby]

Have you tried old thin clients for this? They're often much cheaper than a Pi, and usually fanless. My only reservation is how much memory and storage you need for a full GUI install compared to something minimal like daphile (headless, uses LMS and BruteFIR).

Yes, old thin clients are a really nice option. Cheap, often fanless, and usually built better than you’d expect for the price.

I did most of the FXRoute work on a fanless Celeron N3350 with 8 GB RAM and 64 GB eMMC. It is slower than a Raspberry Pi 5, probably closer to Raspberry Pi 4 territory. Definitely not a rocket, but still quite usable once you avoid heavy desktop stuff like 4K and keep the system a bit trimmed down. Audio playback was never an issue, even with high bitrate content.

So in practice, pretty much anything newer/faster than that N3350 should be totally fine.

I’m on a almost palm sized N150 now with 12 GB RAM and a 512 GB SSD (spend less then 200$, good price for this times), and it flies.

Edit, had a look:
Right now i am on Tumbleweed and it consumes about 2GB RAM with all i need loaded.

 

[somebodyelse]

Borderline for my old Wyse R90L (<£20 a few years back) but if anyone wants to check specs https://www.parkytowers.me.uk/thin/hware/hardware.shtml is a good resource.

I've not looked into how PipeWire is being run in embedded use cases, but based on one of the presentations about time sync between clock domains it appears to be in commercial use that way. That might allow slimming it further for headless use.

 

[cobby]

Yes, that’s pretty much my take as well. The R90L feels right on the edge, but little newer thin clients should be a much safer bet (2016+). PipeWire in embedded/headless setups is definitely interesting though.

 

[john61ct]

Localization Cue Correction (LCC)

I don't understand if LCC is theoretically correct, and that bothers me. I might as well have just applied a SoundGoodizer, for all I know. And that would go against my desire for accuracy. Here you go: https://equipboard.com/items/image-line-soundgoodizer-software-maximizer-enhancer-plugin...

www.audiosciencereview.com

 

[cobby]

Localization Cue Correction (LCC)

I don't understand if LCC is theoretically correct, and that bothers me. I might as well have just applied a SoundGoodizer, for all I know. And that would go against my desire for accuracy. Here you go: https://equipboard.com/items/image-line-soundgoodizer-software-maximizer-enhancer-plugin...

www.audiosciencereview.com

EasyEffects is normally the standard host, yes. The reason for a fork is probably that this effect was integrated directly into EasyEffects rather than shipped as a separate plugin.

For FXRoute, that does not automatically mean it would be incompatible. What matters is whether that modified EasyEffects still behaves like a modern EasyEffects build on the control side.

So in practice:

- you would usually use one EasyEffects install, not two in parallel
- if the fork is based on EasyEffects v8+
- and it still provides the same control socket/API

then FXRoute should still be able to use that EasyEffects installation.

That said, FXRoute would not have explicit GUI support for that custom effect unless support for it was added specifically.
In that scenario, the custom EasyEffects would probably just have to be installed manually first, and FXRoute would detect it and use it.

 

[john61ct]

I've been through "Dependency Hell" before in Linux.

Worst case run in separate VMs or containers?

 

[cobby]

Yes, I totally get the dependency hell concern - that is exactly why FXRoute uses and installs the EasyEffects Flatpak by default if no EE was previously installed (like mentioned Version).

For normal FXRoute use I would personally prefer bare metal. No VM or container should be needed.

The only unknown here is the custom EasyEffects fork. It may be great, but I don’t know that build or its dependencies. Testing it on a spare/test system, VM, or container could all make sense, depending on what someone is comfortable with.

 

[somebodyelse]

The fork appears to be there just for development of a new feature (the lcc plugin) and is otherwise fairly current, missing only commits on or after April 21st. There's an upstream issue for its inclusion, with largely positive comments from upstream, but no pull request as yet. It seems like it meets the criteria in #15 above, so should work.

 

[cobby]

Small FXRoute update: preset combine for DSP

I added a new Combine workflow for DSP presets in FXRoute.

You can now create a new preset from multiple existing presets without touching the originals, which makes experimenting with different DSP chains a lot easier and faster.

I also cleaned up parts of the DSP/PEQ workflow a bit along the way, so the whole section feels more polished now.

 

[yelloguy]

Love this! Probably not for me atm

I agree that old PC's are better than Rasp Pi in a lot of cases. But I went with a rasp pi for my specific need - which is to playback to a USB Audio Interface. Pi in a case is smaller than the USB interface so practically invisible