Talking to a colleague today about what would keep me from moving full-time to Linux. The biggest thing is Audio Hijack and Rogue Amoeba apps in general.

Does anyone know of something we don't know about for Linux? The ability to treat the OS sound subsystem like a studio mixing board is just so great.

@hund please boost this to your Linux folks for better coverage, if you don't mind 😀

And for the record, I might just say "fuck it" and build a mixer with little arm boards if I need to ...

@Unairedspecifics @alrs Any JACK GUI you can recommend in particular? It looks like it's pretty powerful but also cumbersome to use (reading the "How Can I" bits of the FAQ). A good GUI could of course make that go away.

@tfb @Unairedspecifics I'm from the '80s, graphical user interfaces confuse me.

on the top of my head i can't recall a gui to manage it.

General-purpose computers are horrible for real-time applications.

@amiloradovsky Audio is such an easy one though. The real-time constraints of audio routing became child's play for GP computers more than 20 years ago .

Maybe, but ~10 years ago I was making a toy music synthesizer, driven by the keyboard from X11 — the delays were so large that I almost couldn't play anything recognizable.
Perhaps I could get faster response by avoiding X11… but I decided to just make it command-driven (typing in commands, listening to the sound they generate, and assemble them into a text file, which would be later compiled into .au).

Being truly real-time means having guaranteed upper bounds on the response times. This is a problem, if not directly within the scope of then at least directly adjacent to formal verification — that is, very difficult.
See also: cost semantics.
Common software and hardware aren't suited for this type of applications: they're too complicated, due to the need for backward-compatibility and "general-purpose'ness"… — It's the realm of , , / , etc.

@amiloradovsky @tfb hmm
but do you need strict real-time for music? isn't soft real-time enough?

Well, for a toy/game, a good response time, most of the time, would suffice, even without the strict guarantees.
One solution is to just get a more "powerful" hardware…
How to tune the common s/w, and what h/w to buy within a fixed budget is another question.

@amiloradovsky @grainloom @tfb

AFAIK real-time operating systems are not "faster" than non real-time ones they just provide predictable resources to user space programs that are carefully designed to get advantage of them, in systems carefully designed to avoid deadlocks or requirements' contraddictions between the running processes.
If you need better hardware, a real-time os will not help, sometime even if everything it run is carefully configured.

@amiloradovsky Non-toy soft synths have been perfectly normal for two decades now.

The last soft synth I built was a transistor-level simulation (with some shortcuts) of a 4-oscillator analog synth. It ran fine from a USB midi controller, in a Linux VM on a 2013 MacBook Pro. Just mostly-functional F# on Mono, so no micro optimizations.

The Korg soft synths make a whole suite of patchable instruments. Super fun, and playable.

Yes, I heard of later, but didn't have enough interest/energy to figure out how to actually use it. — The software synthesizers is something that should exist in abundance, but, when I searched for an actual working libre software and examples, I couldn't find anything, besides the proprietary, coming on DVDs…
Also, the machine I was testing my toy synth on was an "office PC" from 2003…

@amiloradovsky There are a ton of synths on Linux. See for some. Some of these existed back then, some not. There must be three orders of magnitude more commercial ones.

Nice. Should find time to look into some of them. — The last sound creation/editing software I used were and

@tfb I think you are looking for Jack Audio Connection Kit

Sign in to participate in the conversation
Functional Café is an instance for people interested in functional programming and languages.