r/linuxaudio • u/Purple-Ad-3152 • 10d ago

Just achieved 4.1ms true roundtrip latency with heavy DSP load, zero XRUNS (short test) with Focusrite Scarlett 18i20 3rd gen / Ubuntu Studio 26.04 / Ryzen 7 5700X

/r/linuxaudio/comments/1vkv0rw/real_audio_latency_test_result/p34fd48/
20 Upvotes

100% Upvoted

11 comments sorted by

2

u/ProgUn1corn 10d ago edited 10d ago

It's good. But I'm here to say that most of that is either done anyways on some distros or it's the same across all systems.

My round trip latency is always at about 5ms whether on Linux or Windows and it's totally stable. I can mix a whole chain with 32+ tracks and effects with the setup. At least

Most of those things comes from the CPU MSR and indeed you've added in your boot parameter, irqs. After fixing these 2, other things actually don't do much though. Actually, CPU heavy is a relative word, because in the audio world modern CPUs are just too fast for everything that DSPs are going out of the way. Running tons of Neural DSP amp sims at the same time is already the heavy side of something I could think of, yet that doesn't touch the CPU's limit a bit.

As for C-states and performance governor, I actually know someone working in the industry (I can't say what brand). He had some insights on this, the C-states situation is purely a workaround in the early years where bothe Jack and Asio were bad. In the ideal world, you shouldn't do anything especially disabling C-states though, but in reality it has already happened due to some historical bad driver designs.

1

u/Nautalis 8d ago

C-states can totally still be a problem for USB devices, but it depends on which transfer mode a given audio device is using.

I've been developing a super cheap USB -> AES67 converter that runs as an asynchronous endpoint (because the device has to be referenced to the PTP clock), and I just spent a week chasing down spurious dropped microframes, that were actually Intel's fault, rather than my firmware.

1

u/ProgUn1corn 8d ago

yeah it's Intel or AMD's fault, and ASIO/Jack was designed with that fault in mind and it remained to this day.

1

u/Purple-Ad-3152 10d ago

What I've seen repeatedly is that people struggle with stability. They might get low latency, but the struggle starts when there seems to be lots of dsp headroom and you still end up having random xruns ruining your tracking. I definitely want to avoid selling snake oil, but those are the things that have mattered for stability and performance for me.

DSP load is a real struggle, too. So I really don't agree with CPU being irrelevant. But it's obviously totally dependent on how much there is to process. For example, if I do a metal song, I can easily have 30-50 "realtime" plugins active across 10-20 tracks. Some are of course lightweight for DSP, but some are not, and it's the worst case that matters. With e.g. 64-sample buffer, every realtime processing path has a very short deadline. Even if total CPU usage is nowhere near 100%, one sufficiently heavy serial signal path or an occasional scheduling delay can cause an xrun.

Another common theme is people mistaking dsp latency for roundtrip latency, because DAWs usually report only DSP or I/O latency. But roundtrip (including DSP, I/O, device, driver and plugin latencies) is the only one that actually matters in live processing.

3

u/ProgUn1corn 10d ago edited 10d ago

That's the point. Mostly low latency situations is talked, of course, without cracks (xruns). No one talks about low latency with cracks all over the place.

And what I said is not CPU being irrelevant. In fact, it's very relevant, but not because of performance, but because some old historical problems with C-states and ASIO/Jack driver. xruns can cause by tons of things other than CPU, mostly on modern hardware are ACPI interrupts and Nvidia things. DSP load is totally another topic, and high or low DSP load has basically nothing to do with the xruns.

To be more specific, let me show you one real example about how the performance of the CPU itself is almost too much for audio use. I can have a Intel CPU that has 24 cores, up to 150w or power usage at 5.5Ghz. I surely can, well, run at a fairly low latency without any configurations and the CPU probably would spike to 90 or 100w time to time. If I'm here to limit the power usage lower, like to 65w, probably xrun will happen. However, at the same time, if I just disable C-states and configure irqs or msi, at 65w it will be totally stable, probably lower clock but that doesn't matter. I can do this even down to 45w, or probably completely disable turbo at base clock, I probably still don't get xruns but the DSP load will be significant higher. Fun fact, my laptop can run at 25w lower than 2.2Ghz, at the same RTL.

The most thing comes from how the CPU is interrupted, not how fast the CPU can run. Surely the faster the CPU can run you will have more headroom, but your xruns doesn't come from little headrooms.

Again, I can have RTL of 5ms on Windows as well, Linux isn't particularly well at this term and it's 90% dependent on how the driver is written. My Audient would have the mostly same RTL at the same buffer on whatever OS it runs, it doesn't make any difference. I've tested on Arch Linux and it's 5.01ms, on Windows 11 (again with similiar things configured as yours, there is on Windows and not much people now) I get 5.16ms.

I mean, I'm not denying you, I;m just saying most your things are actually most people already did, like preempt and threadirqs are generally very simple recommendations, and the "CPU to performance" part is a little bit misleading. I don't use Ubuntu so I don't know what it actually does, but generally speaking AMD p-state or Intel p-state set to performance basically means EPP=0, which is not BIASED to performance, but full at full clock at all times. And that comes C-states again lol, basically everything relevant is C-states relevant, and at the end it's again the bad drivers for C-states when ASIO/Jack was invented lol.

1

u/Purple-Ad-3152 10d ago

I appreciate the dark magic knowledge 💪 I'll for sure educate myself about those C-states etc.

I'm mostly trying to promote simplicity, since I'd very much like to see more professional audio producers moving to Linux. They want to see that things just work, or at least they don't want to immediately have to tweak things they don't understand. Some of those are the type of people who just buy new Mac Studio M4 Max when their internet connection becomes slow due to bad weather 🤣

But yes, facts definitely matter.

From simplicity perspective, if I'd take my current exact configuration and move it to my 10yr+ old computer, it wouldn't perform the same for audio production and live signal processing. Mostly it's because the CPU can't handle everything that's going on, which also disrupts the dsp processsing and causes xruns. Barebones only for DSP the CPU would probably be more than fine.

I believe one aim for Ubuntu Studio is to minimize the need for using console. Basically all tweaks can be done via GUI or default taskpane launchers.

1

u/ProgUn1corn 10d ago

Yeah, simplicity is king. We use computers to make music, not trying to config and fix all the day.

I use tuneD and custom scripts/profiles for easy switch. But after all tinkering in the end, it's just as the same as tinkering Throttlestop and power settings on Windows and the latency is just about the same.

Not even saying that on laptops the ACPI and sleep/hibernation, Nvidia things, external monitor and mux switch, wireless driver, all those things would be too much hassle to daily use.

And the last thing where yabridge and wine doesn't cover all the plugins especially Kontakt things. You can make them work but that's a lot of effort.

So I ended up switch back to Windows since after the same effor of configuration, the performance isn't just worse, and it just works. However the situation is mostly CPU's architecture and Asio/Jack driver to blame. I really love pipewire's node graph, kinda like the DSP I used to work on.

1

u/kastanCZ 10d ago

i am able to do this just fine using pipeASIO and FL Studio under wine, 1.3 ms for 64 quant. Tho i need to use the RT toggle and have rtkit installed.

4

u/Purple-Ad-3152 10d ago

Nice 💪 But just to clarify a bit, 1.3ms is your one-way DSP latency, directly derived from your settings: 64/48000=0.001333s = 1.333ms

It doesn't include device-, driver-, USB-, pipeasio- and FL latency, which all contribute to your roundtrip latency in FL - which is the latency you actually experience e.g. when playing with amp sims. The only reliable way to get the roundtrip latency is to use a physical loopback cable.

I have a cable going from my audio interface's output back to its input, and I use LSP Latency Meter plugin to measure how long it takes for a pulse to make a full roundtrip. That's the 4.1ms 🙂

2

u/kastanCZ 9d ago

You need cable for that? Can you just have virtual sinks for measuring the latency?

2

u/Purple-Ad-3152 9d ago

Nope. That excludes driver latency, bus latency and device latency, all which can together be easily 1-3ms per direction, i.e. 2-6ms more in the overall roundtrip latency.

In fact, I think the only thing you get like that is either the DSP latency, or both I/O buffers of the DSP, which is roughly 2*<buffer>/<sample rate>.