Considering Linux for my next music production computer - wise or not?

[kvotchin]

Looking into LMDE most recently. A contender, perhaps? I like Mint’s general approach, but “pure” Debian might be a better foundation, and apparently it runs faster, and has less frequent updates.

[Boone777]

I fell in love with Linux and was making music with it for 3 years. It was a steep learning curve for the first 2 weeks it did not help that I had a old frankenstein PC and making everything work was a lot of reasearch.

Pure Alsa worked well for me but I could never have Pipewire work to my liking either latency wise or crackling and dropouts. I constantly had X-runs with Jack.

My best experience was with Manjaro I had everything up and running but at one point it froze and I could not open it anymore. My favorite distro is MXLinux. I love that it creates an iso of your full installation that can be installed anywhere afterwards or use live on a usb drive. When they went full Pipewire it was worst for me I had to change distro again but...

As an alternative I highly recommend trying to find a custom Win11. They are out there and some of them are very lightweight, build for performance and completely debloated of all the windows crap we hate. Now I can run every single plugin I bought over the years and it's a pleasure to use.

[Drum4Drum]

Looking into LMDE most recently. A contender, perhaps? I like Mint’s general approach, but “pure” Debian might be a better foundation, and apparently it runs faster, and has less frequent updates.

I highly doubt that you will notice any performance differences, so pick what you like more.

[lunardigs]

The Pipewire stuff is pretty huge for pro audio. For me it was huge quality of life upgrade.
Btw, in case it wasn't mentioned before; RaySession is a really good session manager GUI: https://www.raysession.tuxfamily.org/ma ... troduction

[camsr]

I tried QPWGraph to route application audio into a host, and it works but not without flaws. I recently had a hard system lock after closing a DAW app (reaper i think, might have been Carla) while the QPWGraph was still active. I had to hard power off then, so warning to users now I haven't tried the "Pro Audio" mode yet. REAPER gives over 1 second of latency in PulseAudio mode with QPWGraph, I tried every setting I could think of to change that, nope didn't work. Appearantly in both REAPER and Carla I must use the PulseAudio device for QPWGraph to work as intented. Carla had no extreme latency though, but also isn't working with graphical JSFX Scripts either. I will probably find more issues as I dip my toes deeper.

[mabian]

I use alsa, probably somehow wrapped in pipewire, or pw-jack, which is pipewire jack, especially with the first I can work at 48khz with 128 samples, around 7ms in reaper, with a fair amount of plugins, many of which are through yabridge. Linux Mint 22, normal kernel (not the realtime one). Not flawless but workable.

[camsr]

my 99-pulse-safe.conf file:

Code: Select all

stream.properties = {
    audio.rate = 48000
    api.alsa.period-size = 2048
    api.alsa.headroom = 2048
    resample.quality = 4
}

my 99-sample-rate.conf file:

Code: Select all

context.properties = {
    default.clock.rate          = 96000
    default.clock.allowed-rates = [ 96000 ]
    default.clock.quantum       = 512
    default.clock.min-quantum   = 32
    default.clock.max-quantum   = 2048
}

yes i am upsampling to 96khz on the output. these files were AI generated too (except for resample.quality = 4 i changed that)

[camsr]

here is an example of output from pw-top utility:

Code: Select all

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME                                             
S   29      0      0    ---     ---   ---   ---     0                  Dummy-Driver
S   30      0      0    ---     ---   ---   ---     0                  Freewheel-Driver
S   40      0      0    ---     ---   ---   ---     0                  Midi-Bridge
R   48   2048  96000 170.8us  48.2us  0.01  0.00  181    S32LE 2 96000 alsa_output.pci-0000_00_1b.0.analog-stereo
R   68   8192  96000  26.4us  62.7us  0.00  0.00  146    F32LE 2 96000  + Carla
R   49    512  96000 405.9us   0.7us  0.08  0.00   12    S32LE 2 96000 alsa_input.pci-0000_00_1b.0.analog-stereo
R   61    512  96000   5.7us  16.9us  0.00  0.00   79    F32LE 2 96000  + Carla
R   54   3307  44100  22.7us 104.4us  0.00  0.02  222    F32LE 2 44100  + Firefox

and using REAPER:

Code: Select all

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME                                             
S   29      0      0    ---     ---   ---   ---     0                  Dummy-Driver
S   30      0      0    ---     ---   ---   ---     0                  Freewheel-Driver
S   40      0      0    ---     ---   ---   ---     0                  Midi-Bridge
R   48   2048  96000 505.8us  32.9us  0.02  0.00  181    S32LE 2 96000 alsa_output.pci-0000_00_1b.0.analog-stereo
R   61 131072  96000   6.0us  19.9us  0.00  0.00    0    S32LE 2 96000  + REAPER
R   88   8192  96000  29.1us  38.6us  0.00  0.00    0    S32LE 2 96000  + REAPER
R   54   3307  44100  69.7us 285.2us  0.00  0.01    0    F32LE 2 44100  + Firefox
S   49      0      0    ---     ---   ---   ---     0                  alsa_input.pci-0000_00_1b.0.analog-stereo

note quant value at 131072, totally wrong and bad

[j_e_g]

Pipewire is a yet one more colossal misstep in the evolution of linux audio. It tries to surreptitiously replace Pulse Audio, Jack, OSS, and anything else it can get its misguided hands on, without the knowledge/consent of programs that use those audio functions. The net result is that it alters the behavior of your entire music environment, in ways from subtle bugs to "Just Breaks Things". If you've spent months fine-tuning your linux audio system to work just the way you want it, you're just one Pipewire upgrade away from having to start all over from square one.

The lack of discipline among linux audio developers in regards to not repeatedly and unnecessarily replacing working code with yet more ill-conceived, unproven crap (with "new and improved" bugs) makes linux audio wildly unreliable, unstable, and prone to sudden failure. As such.I definitely would urge people to NOT use linux for music creation. (OTOH, I would recommend it for most other tasks. It's only linux audio devs who insist on tearing everything apart every 2 years or so. Seriously. The next major audio disruption should happen in 2027 if history holds.)

I hate to say this being that I write linux music software, but folks need to hear the truth. You WILL have major problems getting music software working well on Linux. Incompetent Linux devs have been ripping apart the audio support in the operating system, and duct taping it back together, for so long now that it's irreparably broken. Stay away.

[uOpt]

The lack of discipline among linux audio developers in regards to not repeatedly and unnecessarily replacing working code with yet more ill-conceived, unproven crap (with "new and improved" bugs) makes linux audio wildly unreliable, unstable, and prone to sudden failure. As such.I definitely would urge people to NOT use linux for music creation. (OTOH, I would recommend it for most other tasks. It's only linux audio devs who insist on tearing everything apart every 2 years or so. Seriously. The next major audio disruption should happen in 2027 if history holds.)

Well, I am doing fine with jack. No steps have been taken to disable jack if you don't want pipewire.

[audiojunkie]

Pipewire is a yet one more colossal misstep in the evolution of linux audio. It tries to surreptitiously replace Pulse Audio, Jack, OSS, and anything else it can get its misguided hands on, without the knowledge/consent of programs that use those audio functions. The net result is that it alters the behavior of your entire music environment, in ways from subtle bugs to "Just Breaks Things". If you've spent months fine-tuning your linux audio system to work just the way you want it, you're just one Pipewire upgrade away from having to start all over from square one.

The lack of discipline among linux audio developers in regards to not repeatedly and unnecessarily replacing working code with yet more ill-conceived, unproven crap (with "new and improved" bugs) makes linux audio wildly unreliable, unstable, and prone to sudden failure. As such.I definitely would urge people to NOT use linux for music creation. (OTOH, I would recommend it for most other tasks. It's only linux audio devs who insist on tearing everything apart every 2 years or so. Seriously. The next major audio disruption should happen in 2027 if history holds.)

I hate to say this being that I write linux music software, but folks need to hear the truth. You WILL have major problems getting music software working well on Linux. Incompetent Linux devs have been ripping apart the audio support in the operating system, and duct taping it back together, for so long now that it's irreparably broken. Stay away.

Last we heard from you, Jeff, you were refusing to even try to learn how to use Pipewire, because you had heard somewhere that Pipewire was meant to replace PulseAudio. You were refusing to even try it, and instead were calling it PulseAudio version 2.

My questions for you: Did you bother to learn how to set up and use Pipewire? Did you actually test it and do the required configurations to get solid low latency audio? Or are you simply doing what you did at the linuxmusicians.com forums, and just complaining about it without actually using it? You were very verbally against the idea before it was even available, and used the problems that existed during the Pipewire betas to prove your points. Has this changed?

EDIT: BTW, why did you get banned from the Linux Musician's forum?

[j_e_g]

you were refusing to even try to learn how to use Pipewire, because you had heard somewhere that Pipewire was meant to replace PulseAudio. You were refusing to even try it, and instead were calling it PulseAudio version 2.

I believe that you're misquoting my past posts, I don't dislike Pipewire because it replaces PulseAudio. In fact, I argued that it should do that, and NOTHING MORE, I dislike Pipewire because it also replaced Jack, UNNECESSARILY SO. It took years to get PulseAudio and Jack to transparently work together, Pipewire threw that away by choosing to replace JACK too, instead of transparently making PW work with actual JACK by simply implementing PA's DBus "Device Request" protocol. The latter would have been MUCH less code churn (which would have made those initial PW releases less buggy). The way it is now you can't use real JACK if you've got PW running. That was stupid and unnecessary. It also means that JACK development is now tethered to PW development instead of being an entirely separate project maintained by people who understand Jack's complicated architecture, (I understand it because I did a several months code review of Jack). PW devs don't understand it beyond merging the code. They will not be developing JACK any further which means Jack is now a frozen, dead code base. I know this because I challenged Wyn to address a number of concerns I had about merging Jack into PW. He admitted that he shared those concerns but had no answers to ANY of those concerns (and yet had already merged jack).

In fact, I had PW inflicted on me several times due to distro updates that pushed it. My first encounter with it caused it to make my software unable to get audio through JACK, A later update did solve that. But the latest version pushed on me has reintroduced that problem. It should never have happened, and wouldn't have if Wyn didn't have the hubris to think he could easily merge jack instead of simply gotten the APIs to coexist a la PA.

]Did you bother to learn how to set up and use Pipewire?

My point is that I shouldn't need to do that if PW devs had done the correct, sensible thing in the first place.

what you did at the linuxmusicians.com forums, and just complaining about it without actually using it?

I articulated numerous problems with it (including points made above) that shouldn't have been issues if PW devs had done the correct, sensible thing in the first place Again, you misrepresent my past posts,

you were very verbally against the idea before it was even available

Because I had the foresight to anticipate the reasons against merging JACK and PW code. (Not to mention PA).

used the problems that existed during the Pipewire betas to prove your points.

Those were buggy and poorly performing because the PW devs neglected to anticipate the reasons against merging JACK and PW code, took on more they could handle, and failed to deliver what they promised. This is a common problem with devs who code first, and consider the issues second (if ever).

BTW, why did you get banned from the Linux Musician's forum?

Because I made a (obviously absurd) joke about making a deal to get favorable treatment from the moderator in exchange for exclusively using his gay escort service. I didn't realize that, unlike raboof, board operator Matt King is a humorless homophobe who went completely berserk and banned me instantly.

And thank god he did. (Well not his god who appears to hate gay people) I've saved lots of time not having to wade through endless posts from musicians trying to fix their linux audio issues. KVR has a lot less of those posts because hardy any musicians here use linux due to not wanting to "bother to learn how to set up and use Pipewire".

Thank you for giving me the opportunity to laugh about (or as reboof puts it "make snarky comments about" -- hey everyone needs a career) the tragic fate of OS's whose devs do crazy inexplicable things in lieu of what endusers actually want. THAT I do miss.

[audiojunkie]

Just like a politician, you completely sidestepped my question—did you ever give Pipewire a fair shake. I’ll take that sidestep and answer avoidance as a “no”.

I can assuredly tell you that most people I’ve spoken to or chatted with find Pipewire a godsend and a huge step forward. The performance is the same. The setup is easier, The sound server on top of ALSA has finally had the grand unification that it has needed for two decades. Just because you are against it doesn’t mean progress is going to stop. Linux keeps getting better and better. You probably are against systemd as well.

Besides, JACK was abandoned. FalkTX took it under his wing to keep it alive, but it was essentially on life support—just like Non. Pipewire is alive and well, and is continuously improved. All major distros have adopted it. Whether you believe it is progress or not is irrelevant. Pipewire is the new standard Linux audio server, whether anyone likes it or not. And I like Pipewire.

[camsr]

I will take the bait. I would prefer to enable only what is needed at the time to get the audio device (or devices...) working as expected. Is the PW abstracting over the issues to hide implementation details that it is unaware of? Is JACK any better?

[audiojunkie]

I will take the bait. I would prefer to enable only what is needed at the time to get the audio device (or devices...) working as expected. Is the PW abstracting over the issues to hide implementation details that it is unaware of? Is JACK any better?

Not to my understanding. JACK doesn't even need to be installed anymore on distros that come with Pipewire already installed. Pipewire handles everything that JACK did through Pipewire-jack. The only thing to know, is that in order to benefit from the same type of scheduling (IRQ), you need to be running pipewire with the Pro Audio profile. If Pipewire isn't being run through the Pro Audio Profile, then Pipewire won't be using the same IRQ scheduling that JACK used. Some people don't know, or haven't bothered to learn about this, and so they don't realize that they aren't getting the proper scheduling that provides the low latency audio.

Also, just like JACK, the kernel needs to be running with Preempt=full and threadirqs kernel parameters or else the audio threads won't be available for prioritization. Many people don't realize this either, because the realtime patches were only recently mainlined into the kernel. There is no longer a need for a realtime or low latency kernel--the default generic kernel has it all built in now. Old timers that are unwilling to learn the requirements to get everything working properly with the new software often miss this part as well.

And after that, there still needs to be a start-up script that prioritizes the audio threads. This is also something JACK required. An example of one of the scripts that does this, is "rtirq".

As I said, everything is integrated, and works great! If people aren't seeing the results that they are expecting, they are missing a step in the set up and configuration of the system. These people who don't know how to set it up, or are unwilling to learn how to set it up (and instead just complain about it without actually trying it) can easily use something like AVLinux or Ubuntu Studio or LibraZiK to easily benefit from Linux Audio without having to manually set anything up.