LinuxMusicians

Try the Arch kernel too - if anyone is reading this... worked better than every other distro for audio... on several systems .. this last year... for me.

What do you mean? Could you provide a comparison?

There is a lot of good information here. One thing that I am still wondering about is, how does the USB interface relate to DSP load. For example, one a single track with bunch of demanding plugins Carla shows high DSP load while the "Performance Meter" in Reaper shows around 15% RT load at the same time. So i was wondering if another USB interface could help with that or if the CPU is limiting.The interface is a Focusrite Solo 2nd gen and the CPU a Ryzen 5 3400g with 3200 mhz DDR4.
I've read somewhere, can't remember where, that on the Focusrite 2nd gen devices the DSP does the heavy lifting and on 3rd gen device the CPU (loosely paraphrasing here). So I was thinking about getting a better interface like an Audient44 to run more plugins at the same time, but I am just not sure if that would solve the problem of high DSP load or if I need a faster CPU like a new AMD APU (don't need a seperate graphic card). If someone has some info on that, I'd greatly appreciate it.

Toejam76 wrote: ↑Sun Nov 14, 2021 8:04 am There is a lot of good information here. One thing that I am still wondering about is, how does the USB interface relate to DSP load. For example, one a single track with bunch of demanding plugins Carla shows high DSP load while the "Performance Meter" in Reaper shows around 15% RT load at the same time. So i was wondering if another USB interface could help with that or if the CPU is limiting.The interface is a Focusrite Solo 2nd gen and the CPU a Ryzen 5 3400g with 3200 mhz DDR4.
I've read somewhere, can't remember where, that on the Focusrite 2nd gen devices the DSP does the heavy lifting and on 3rd gen device the CPU (loosely paraphrasing here). So I was thinking about getting a better interface like an Audient44 to run more plugins at the same time, but I am just not sure if that would solve the problem of high DSP load or if I need a faster CPU like a new AMD APU (don't need a seperate graphic card). If someone has some info on that, I'd greatly appreciate it.

I didn't read the whole topic, sorry.

But about (USB) audio devices. If I'n not mistaken Focusrite audio devices require a (reverse engineered?) driver in Linux. I don't think that will cause latency and/or Xruns but it might: you never know. If you want to experiment with getting less latency/xruns and audio devices you might try a "driverless" out of the box working audio device like the U-Phoria ones from Behringer (link example of one at Thomann). Most say they're not bad for the money (Midas pre-amps, whatever that may mean) and for comparison of xruns/dsp load ideal I think.

@Linuxmusician01
I don't have problems with latency or xruns. It's just as good as on Windows or Mac, but I wanted to know if I could get better performance with a new interface or rather get a new CPU (APU), because DSP load is on the edge according to Carla with a few "big" plugins like Arturia or Kontakt stuff.

Toejam76 wrote: ↑Sun Nov 14, 2021 8:04 am One thing that I am still wondering about is, how does the USB interface relate to DSP load.

I would have thought it doesn't. What's called an 'interface' these days is really a 'studio in a box'. I f we think what an interface is -- it has an analogue input and a digital output that a computer understands.

Guitar > A/D convertors > USB > Software

All the other features, like mic pre-amps and direct monitoring used to be separate boxes.

So really an interface is quite simple. All USB interfaces on Linux use the same driver -- snd-usb-audio -- so there shouldn't be a lot of difference between different models and brands. As with everything it has to be tested before a definitive statement can be made, and in practice there may be some variation. But as far as the idea that improved audio performance is something that can be bought by upgrading an interface -- I think that's a fiction convenient for manufacturers who want to sell interfaces to slack jawed consumers a.k.a. Windows users Parallax scrolling websites showing guitar playing hipsters plugged into the latest hardware sell interfaces; they might not be so good from a technical information point of view.

Other opinions, and particularly data welcome.

For example, one a single track with bunch of demanding plugins Carla shows high DSP load while the "Performance Meter" in Reaper shows around 15% RT load at the same time.

I haven't used Reaper much, so I haven't experienced that. Could it be single/multi thread? As far as I know Kontakt is single threaded, so it could use up a single core before the whole processor is maxed out. From what you say there appears to be some difference between how Reaper and Carla define DSP load.

I've read somewhere, can't remember where, that on the Focusrite 2nd gen devices the DSP does the heavy lifting and on 3rd gen device the CPU (loosely paraphrasing here).

I don't think that's the case. Take e.g. an RME card that has DSP built in -- it can only process the signals on the card. If a USB interface did do some of the DSP audio data would have to be sent back and forward between the computer and the interface, increasing latency, which I'm fairly sure is not happening. Again, anyone with evidence to the contrary please post.

If a USB interface did do some of the DSP audio data would have to be sent back and forward between the computer and the interface, increasing latency,

That's a good point and makes total sense. I was thinking that the USB DSPs are doing something similar like those internal DSP cards.

@LinuxMusician01

If you want to experiment with getting less latency/xruns and audio devices you might try a "driverless" out of the box working audio device like the U-Phoria ones from Behringer

Maybe related to that I found out, that using the on-board soundchip (intel_hda) doesn't make any difference to the latency or load. It's exactly the same, but I have to use JACK again instead of only ALSA with Reaper. That tells me that the Scarlett Solo interface seems to be only a I/O box. That's ok, because now I know that upgrading the cpu and faster ram makes more sense than getting another interface. A DSP like those DANTE cards would probably also make a difference, but I am scarred of the configuration.

All your plugin processing is done by your CPU so if the load is getting too high that is where you need to focus. CPU, ram and HD speed if you are doing a lot of channels perhaps.

I find the latency with USB to be negligible. Apparently there are patches on the way in an upcoming kernel that aim to reduce it further.

I don't think thunderbolt adds much improvement. If can't notice a latency difference between my PCI interface and my USB interface I suspect I won't on thunderbolt either.

The devices that are adding processing onboard I believe are primarily targeted for windows users who are trying to create a low latency processed monitoring mix. People don't want to hear a dry mix in their monitors. In a properly tuned Linux system I don't think this has ever been an issue. In windows I think it has been a cronic problem. To me it seems like a convoluted signal chain and I would think a realtime linux system should still be better, but I have not tried these. Windows people seem happy with it. Don't expect these devices to ever be supported in Linux. At least not the signal processing functions.

The real trick that producers want is to record with compression / EQ / etc. applied to the original signal: "record what you would want to mix" is their mantra. The bonus of having the singer hear an already-compressed signal, with some form of reverb, is a big win as well. Note that applying *some* kind of reverb while tracking is less important than having a reasonable amount of compression applied to the vocal-as-heard-in-monitors.

Try the Arch kernel too - if anyone is reading this... worked better than every other distro for audio... on several systems .. this last year... for me.

I'd also like to know what that statement means?
What is "an Arch kernel"? Why does it "work better"? What is different about it?

The only kernels I know of (which generally pertain to doing audio on Linux) are

- The standard ones that come with most distros - they almost always suck for audio, that is unless Lennard Poettering is your hero.

- Then there are the low-latency & PREEMPT ones (and their mild variations in what options they were compiled with) which offer a big improvement imo w. jack.

- For the hardcore fans there are RT kernels which I avoid because performance gains (for me) seemed minimal (if any at all) and didn't justify the system lock-ups and maintenance hassles. Some users will claim how well their systems run with RT kernels and they never have lockups. Well sure, as long as you don't use it for tasks other than a dedicated narrow field of use it might be OK. Try running VM's etc and thar she blows. But hey, maybe I'm just doing it wrong.

asbak wrote: ↑Wed Jan 26, 2022 6:53 am What is "an Arch kernel"? Why does it "work better"? What is different about it?

The Arch kernel is a PREEMPT kernel. This is the default kernel -- there is no 'stock' or 'generic' kernel available when installing Arch.

- For the hardcore fans there are RT kernels which I avoid because performance gains (for me) seemed minimal (if any at all) and didn't justify the system lock-ups and maintenance hassles.

The benefit of an RT kernel is found when the system is being run near its limit. That could be because you want low latency for a live setup, or because the hardware involved is old. The difference between a PREEMPT kernel and and PREEMPT_RT kernel is that the kernel scheduling latency is lower on RT. That's it. In practice this could be the difference between five xruns in twenty four hours, and zero xruns in twenty four hours.

If you don't mind me saying you're generalising from insufficient data. There are so many combinations of hardware and software out there that what happens on your machine tells you mostly about what happens on your machine. To say anything about the RT kernel in general other combinations of hardware and software would have to be tested to rule them out, and track the issue down to the RT kernel itself.

Or -- YMMV.

merlyn wrote: ↑Tue Nov 02, 2021 1:45 pm

WforWoollyMammoth wrote: ↑Mon Nov 01, 2021 2:00 pm I've noted slight differences between the two USB interfaces I own (RME Babyface Pro and a Yamaha mixer with a built-in interface). It might be due to the hardware differences though.

Are they both USB 2? My friend has a Yamaha mixer that is USB 1.1, and USB1.1 does have worse latency. USB audio uses isochronous transfer. In USB 1.1 one packet is sent per millisecond, in USB 2 eight packets are sent per millisecond, so the diference would be around 2ms.

If you're using JACK you can shave one period off the buffer by using JACK in 'server synchronous' mode.

I'll be interested to hear about your results when you get a kernel with the fixed USB module. Hopefully the latency will be noticeably better.

Sorry for my late answer. I had a move, had left a lot of things in boxes and forgot to reply. I've now done some new tests, because I don't feel comfortable speaking about things that I tested already several years ago.

Here are the results from the roundtrip latency tests I did today with two different USB audio interfaces (RME Babyface Pro and Yamaha MG10XU mixer with a built-in audio interface). I've used QJackCtl for applying the settings. I only have "jackdmp" as the only available server option on my system (not sure if the results would be different with jackd). I only did 128 and 256 frames and 2 and 3 periods for the tests.

OS: Ubuntu 21.04 (though modified quite a bit)
Kernel 5.11.018-lowlatency

RME Babyface Pro

128 / 2 sync = 13.040 ms - QjackCtl reports 5.33 ms
128 / 2 async = 15.707 ms - QjackCtl reports 5.33 ms
128 / 3 sync = 19.207 ms - QjackCtl reports 8 ms
128 / 3 async = 21.873 ms - QjackCtl reports 8 ms
256 / 2 sync = 21.123 ms - QjackCtl reports 10.7 ms
256 / 2 async = 26.457 ms - QjackCtl reports 10.7 ms
256 / 3 sync = 27.207 ms - QjackCtl reports 16 ms
256 / 3 async = 32.540 ms - QjackCtl reports 16 ms

Yamaha MG10XU

128 / 2 sync = 16.530 ms - QjackCtl reports 5.33 ms
128 / 2 async = 19.239 ms - QjackCtl reports 5.33 ms
128 / 3 sync = 21.301 ms - QjackCtl reports 8 ms
128 / 3 async = 24.947 ms - QjackCtl reports 8 ms
256 / 2 sync = 28.114 ms - QjackCtl reports 10.7 ms
256 / 2 async = 33.468 ms - QjackCtl reports 10.7 ms
256 / 3 sync = 36.614 ms - QjackCtl reports 16 ms
256 / 3 async = 41.905 ms - QjackCtl reports 16 ms

It would seem that there's quite a big difference with all the settings I tried! Not sure what causes it (the Yamaha is considerably cheaper, so it has slower converters?). Both units are USB2 and I used the same cable for the tests. I think I had the same type of results with these two audio interfaces when I did the test last time around (I think that was 2½ years ago).

Can anyone point out any potential mistakes I might have made during the tests that might produce these type of results?

These results should, in any case, showcase the additional latency problem with the generic ALSA USB sound driver. Of course, the QJackCtl value isn't for roundtrip, but multiply the values by two for the results that have been done with two periods and you should get a better idea what the latency is "assumed to be" (I have no real idea why the values do not change in QJackCtl when you're using 3 periods).

Again, if I've been doing something stupid and wrong, please someone point it out to me. However, My test results with the RME Babyface Pro are similar to what's been reported e.g. here:
https://www.alsa-project.org/pipermail/ ... 41201.html

I'd be pretty unhappy if the RME did not provide lower latency.

One thing RME likes to claim is the attention they put into their clock. I expect better clock prevents issues that might jamb up the data stream.

Being a hardware mixing device the Yamaha may have additional routing that the RME interface does not have. That would be expected to add latency.

Looking forward to seeing what happens with the updated USB sound driver in ALSA.

I'm not generalising, I'm stating simple facts that RT kernels tended to lock up my systems, sooner rather than later. As I stated, if they work for others then great, and maybe I'm doing it wrong, somehow.

They probably work OK for one-trick-pony users. As I pointed out, when running VM's they tended to crash & burn for me, and I need my system to be able to do more than exclusively run jack or CNC programs.

Hence, the sum total of my RT experience just didn't make it worthwhile for my user case.

Some people's idea of a shangri-la system is to win the lowest latency setting vs no xruns or no xruns vs hours competitions. To me this seems like a pointless exercise.

To me what matters is whether or not one's system xruns when under realistic workloads using realistic latency settings while still keeping latency low enough that it cannot be perceived by most mortals, unless you're Walter Becker or Donald Fagen, ie somewhere in the sub 10ms range.

I'm sure that to get the ultimate in performance that the RT kernel will probably outperform anything else. For my usage case, the performance gains vs the hassle factor didn't appear to be sufficient to warrant wasting more time on it.

Mileage for others may vary.

bluzee wrote: ↑Wed Jan 26, 2022 8:08 pm I'd be pretty unhappy if the RME did not provide lower latency.

I have a RME HDSP 9652, the last time I had it running in Linux it was nothing special in the low-latency department and sending data to its own MIDI interfaces to play softsynths always caused massive xruns. I have no idea why. It worked OK as long as a separate MIDI interface was used. Maybe I just had my setup misconfigured, or maybe other 9652 owners can relate their experiences.

Presumably 99% of the users of these cards in Linux don't even touch MIDI and they use it for audio recording purposes only. ALSA driver dev for it must have ended years ago. In the end I stuck it on a Windows box. (Yes, sacrilege, I know.)

Sadly as is the case with most of the high-end vendors of PC / Audio gear, RME have little to no interest to support Linux.

The much maligned and hated by the "audio professional community" Behringer (if opinion on forums is anything to go by) are one of the few vendors who even bother to offer at least some Linux support for some of their products.