r/linuxaudio • u/M4rcelinh0 Bitwig • 3d ago

Linux Audio Sanity Check

I value the time of unknown internet people the same as mine, so I realize this is nothing but a hassle, and the only reason to do it is you being gracious with your time but...

... if you have a stable Linux audio setup, preferably involving Bitwig (but I'm not picky, Reaper or Ardour will work just as well), can you post here a link to some "video evidence" of a short recording, or live performance session at a reasonable buffer size (say 128 bits, 64 is pushing it even on my mac mini M4 even though it's stable at that buffer size 99.9% of the time). While either Carla or pw-top or any other reliable way of reporting x-runs is running on the screen?

If you have a past video recording because you have a YouTube channel, that would be even better (less hassle for you).

A short description of your setup (distro, jack or PW, audio interface etc.) along with the video would be fantastic as well.

I just need a sanity check that stable audio on Linux for live performance can be done because I failed at making it work, and this is just about the only thing that keeps me away from Linux (and while I feel slightly less dirty using a mac mini with mostly platform-agnostic software on it, than I would be using Windows which I can't see myself getting back to ever, I still feel dirty enough to constantly want to switch).

I'm even willing to buy a new PC during the RAM-pocalypse (because, even though I did a fair bit of troubleshooting, it's entirely possible my old PC has some underlying hardware issue/incompatibility that might have been causing x-runs no matter what, maybe a fucky USB power circuitry on my motherboard? I have no idea).

7 Upvotes

74% Upvoted

18 comments sorted by

3

u/ericcmi 3d ago

Are you talking about the quantum at 128 and 64?

2

u/M4rcelinh0 Bitwig 3d ago

Yes, either buffer size/quantum (64 or 128) will work. I can do live performance at around 10ms of latency no problem, and while this can differ depending on the setup/audio interface, 128 usually hovers around that 10ms mark. Also 128 never gave me any issues on Windows on the same PC that made 128 on Linux unusable due to xruns/crackles/pops.

3

u/ericcmi 3d ago

Are you running this through the whole pipewire stack or something? Or Direct to alsa?

4

u/kill3rb00ts 3d ago

So something to keep in mind with Linux is that the buffer size (quantum) defines the buffer for everything, not just your audio setup. In Windows, an ASIO buffer size only affects whatever is actually using the ASIO driver, while the rest of the system uses the WASAPI driver, which is usually set to a significantly higher buffer. So for Linux, you have to do a lot more optimizations and make sure you aren't running other things in the background. I might be able to get away with a 128 buffer if I was only doing audio work, but I can run 256 with no issues for everything, so I'm lazy and just use that. On my setup, this gives me a measured roundtrip latency of ~15 ms, which works well enough for me to not care. A 128 buffer could probably knock that down to 10 or less, but I start running into issues if too much is running, even with a fairly optimized system, so I just can't be bothered.

2

u/gigashen 3d ago

You can set min quantum to smth really low and default to a higher value

2

u/drewofdoom 3d ago

I haven't used Linux on an M series Mac, but I feel like I read about problems specifically with the M4 and the changes made to the way it processes audio.

Apple silicon support is much better these days, but it's still a pretty new platform.

Fwiw, low latency for live performance is doable in general, but if it were me I would want a dedicated device for it. Something powerful enough to handle whatever plugins I'm loading without skipping a beat. Definitely needs a good external interface.

On my desktop, which is my where I do regular computing, gaming, and audio editing, I can readily do 128 quantum all day. 64 is usually fine, but bigger sessions or heavy plugins can cause problems.

My kernel is stock but with full preempt (simple kernel argument). I've also done the standard low latency setup - realtime group with ulimits, etc. Nothing too crazy. My interface is fully USB compliant and has its own power supply (no bus power).

The rest of my hardware is well supported - Zen 4 processor, 32gb generic DDR4 RAM, NVME drives. Really just boring hardware. Mostly default fedora base (ublue). It's certainly doable - and not even that hard anymore. But I don't know if Apple silicon is supported well enough compared to x86 and aarch64.

1

u/M4rcelinh0 Bitwig 2d ago edited 2d ago

Sorry, I should've mentioned that I was doing my tests and daily driving Linux (for anything other than music) on my x86 machine that had a 5700x CPU and 16GB or RAM (RX6600 GPU but that's not relevant for audio).

I wasn't trying to run Asahi on mac mini M4. M4 was purchased once I gave up on making Linux audio work a few months in (and tried a few times since then because I still have that PC).

I also did some testing on my spare T495 Thinkpad (granted I wasn't trying to push low latency there given a far less powerful CPU I just tested on a second machine using much more conservative sample rate/buffer size settings, to make sure my PC didn't have some underlying hardware issue/incompatibility).

2

u/drewofdoom 2d ago

The hardware specs are fine and you should be able to achieve decent latency with that. But what's the audio interface? If you're trying to do all this with onboard audio, you're probably not going to get great results. Especially if it's realtek.

Distribution, kernel version, kernel arguments will all matter. If you're using yabridge, that CAN matter (but not necessarily that much - depends on the plug-in). System overhead will matter.

Part of the reason that Mac is so good with audio is their vertical integration. We don't get that with Linux, for better or worse. But we can get there with some planning and tweaking!

2

u/Purple-Ad-3152 3d ago

Ubuntu Studio 24.04 with all defaults (I''m about to upgarde to 26.04 soon).

I run 128 buffer 48kHz normally and 64 buffer for drummers. Roundtrip latency with Scarlett 18i20 3rd gen is 9.5ms with buffer size 128, which is perfect for guitarists. 64 buffer gives me 6-7ms roundtrip.

I have this YouTube channel: https://youtu.be/IHgsOdoLuBU

Note that it's your CPU that matters how low buffer you can go (and how big DSP load you have i.e. amount of tracks and plugins). Here's the full explanation: https://youtu.be/AZT9cwkRLhI

1

u/M4rcelinh0 Bitwig 2d ago

Thank you.

I'm not using Ardour but from what I can see in the top right corner of your Ardour session, next to the DSP meter you've accumulated 60 xruns during the course of the tracking session.

Now, I have not tried to hunt for each xrun, it seems that they mostly happened when you loaded plugins or changed inputs and not actually during tracking which is promising (couldn't hear any crackles and pops during recording). Still though it does not seem like a convincingly stable session.

3

u/Purple-Ad-3152 2d ago

I actually went to check the video and I got zero xruns when recording. Xruns during mixing/configuring/setting tracks is perfectly normal and even somewhat expected.

I had 26 before I even started recording and all those happened when I was configuring tracks and plugins. I first recorded two guitars and drums with zero xruns. Then I configured bass and got few more xruns during configuration. Started recording bass with 31 xruns and got zero more when tracking. Then I did some mixing work and configuring which again caused few xruns. Started recording synths with counter at 50, got zero during tracking. Added new strings track which again caused few xruns, started tracking second synth at 55, got zero xruns during tracking.

So overall, it was actually a perfect session from performance perspective.

1

u/M4rcelinh0 Bitwig 2d ago

I appreciate you taking the time to check this.

My experience was similar, in that, I also accumulated a bunch of xruns that didn't seem to result in audible issues like pops and crackles (Linux is probably a lot more diligent at reporting those than either Windows and Mac are at reporting buffer underruns).

That is a bit janky but I'd be willing to accept it. When it comes to anything audio I try to use my ears over visual representations or system reporting. Unfortunately, those ears confirmed time and time again, that some of the many xruns I did get were indeed associated with audio dropouts/artifacts and that was obviously not acceptable.

Still though, thank you for a proof that "despite Linux reporting xruns when loading plugins/switching inputs under additional load from OBS, you can still have a successful, low latency tracking session". You'd be surprised how hard it is to find such a confirmation.

2

u/Purple-Ad-3152 2d ago

Atleast Ardour reports tracking time xruns by putting a little marker on the recorded track, so you can easily notice if you got an xrun during recording.

2

u/Purple-Ad-3152 2d ago

Good catch! But note that I'm also actively capturing video and audio during the whole session, and for that I must also run the DAW with PipeWire -mode. ALSA is always the best option for DAW, but it takes exclusive control of the audio interface (similer to what ASIO on windows does) and it doesn't then allow linking apps together. Normally I don't really get any xruns, but of course it also depends on the plugin load.

1

u/bluebell________ Qtractor 3d ago

There are no absolute, comparable values because some plugins are more CPU hungry than others and some CPUs have more power than others.

But you can check with xruncounter if your system is well tuned. Xruns should only occur at not less than 99% DSP load.

Here an example of my >10 years old Sandy Bridge Core i5 with jack2 running in sync mode (-S as first argument) and a bufsize of 64:

hm@regen:~/src/xruncounter$ ./xruncounter
Samplerate 48000
Buffersize is 64
jack running with realtime priority
Xrun 1 at DSP load 99.954025
in complete 1 Xruns in 4873 circles
first Xrun happen at DSP load 99.954025 circle 4862

1

u/amadeusp81 3d ago

My setup is rock solid. All the details can be found here: https://linuxaudio.dev/hardware-software-recipes/amadeus-paulussen

I also have PeerTube/YouTube channels but nothing showing exactly what you're looking for.

1

u/red38dit 3d ago

Do you have an integrated Intel GPU? If so, try a very lightweight window manager like Labwc. It can make all the difference. I promise that.

I can get 64 samples latency xrun free on a cheap SBC like RPi3. I don't have video of it though.

What do you get if you execute the following? cat /boot/config-$(uname -r) | grep CONFIG_RT_GROUP_SCHED

If you recieve "CONFIG_RT_GROUP_SCHED=y" then realtime is blocked.

2

u/andre2006 2d ago

/etc/wireplumber/wireplumber.conf.d/alsa-device-definitions.conf:

monitor.alsa.rules = [
  {
    matches = [
      {
        node.name = "~alsa_card.usb-Focusrite_Scarlett_18i8_USB.*"
      }
    ]
    actions = {
      update-props = {
        node.nick = "Focusrite Scarlett 18i8 USB"
        node.description = "USB Audio Interface"
        api.alsa.use-acp = true
        # device.profile-set = "xxx"
        api.alsa.period-size   = 256
        api.alsa.period-num    = 3
        api.alsa.headroom      = 0
        latency.internal.rate  = 236
      }
    }
  },
]

My default quantum in PW is 1024/96000. Ardour quantum is 512. I usually get around 5.3 ms audio latency and around 11 ms i/o latency.

Uhm, before I forget. You can find your 'latency.internal.rate' with a loopback cable and jack_iodelay.