01-28-2019, 11:48 AM | #1 |
Human being with feelings
Join Date: Jan 2019
Posts: 17
|
How difficult could it be to get low enough latency on Linux?
This is not directly related to Reaper, but I don't know where else to ask right now.
I've just migrated to Reaper in Debian Linux, after using Adobe Audition 1.5 (!) on Windows 7 for years. It's taking shape, but what drives me crazy is that I can't seem to get good latency. To quote a user at Reddit, "I do the research, buy the recommended gear, follow the wikis and the how-tos, and scour the internet for just about every "no more XRUNs" tips I can find. And still, there I am grooving in the midst of an awesome take and SPLARBPTTTTTTTTT along comes and XRUN and ruins it." I'm using an M-Audio Delta 66 PCI soundcard which have always worked flawlessly in both Linux and Windows. But now when using jack, I can't set the buffer (frames/period) to smaller than 1024 (42 ms lacency) without getting xruns. Never had a problem with it in Windows (ASIO). Currently testing without Reaper, just using jackd/qjackctl and qsynth/fluidsynth with my midi keyboard playing a simple piano soundfont. I've gone through various checklists, such as this one: https://wiki.linuxaudio.org/wiki/system_configuration ... but to no avail. Is it really worth it trying a different kernel? Currently running a newly installed Debian 9 with regular kernel 4.9.130. Any help greatly appreciated! |
01-28-2019, 01:11 PM | #2 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Are you running the latest kernel? They're better now for low latency. I'm not using a "low latency kernel" or "realtime kernel" (see my sig for my system info) and I'm getting latency as good as or better than in Windows. No xruns. It's stable and it's noticeably more CPU efficient in apples-to-apples tests of the DAW.
Did you set your CPU power governor so that your CPU won't throttle down? That's a common step people overlook. It's like choosing the "high performance" power profile in Windows (one very important part of it anyway), a very common thing people need to do for DAW use. I used cpufrequtils to do this and set a startup command to make it persist (it's set to "performance"). |
01-28-2019, 01:51 PM | #3 |
Human being with feelings
Join Date: Jan 2019
Posts: 17
|
Thanks for the suggestions.
At first I was thinking that getting a new kernel probably wouldn't help, but right before you replied, I looked more into the "low latency kernel" thing and tried installing the Liquorix low latency kernel (https://liquirix.net) - and voilà - the xruns are gone! I did test the CPU performance setting briefly yesterday but didn't see any improvement. But I'm not completely sure if I did it properly. Anyway, I'm very happy now with the low lacency kernel, currently running jack at 128 frames/period which gives a nice 5 ms latency. (Actually, qjackctl does report the odd xrun now and then at this latency, but it doesn't produce any noise; and if it does I can always raise it to 256 at least temporarily.) |
01-28-2019, 02:46 PM | #4 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Liquorix cost me more CPU but didn't lower my latency (or allow me to set lower buffer blocksize/periods), so I went back to the stock kernel that MX Linux uses (4.19, Debian Stretch). Then again my blocksize is 128 samples, and I run 4 blocks (at 44.1KHz), a total of 512 samples. I can reduce that by one block (384 samples total) and it's fine too, but for stability right up to 100% CPU use, 4 blocks of 128 samples works best for me. This audio card never could get extremely low latency in Windows (it's no RME card), so the fact it does this well in Linux is good for me. It's 11ms round-trip (measured too, so it's confirmed).
|
01-28-2019, 11:23 PM | #5 | |
Human being with feelings
Join Date: Feb 2014
Posts: 620
|
Quote:
I have a M-Audio Audiophile 2496 and a M-Audio Revolution 7.1 and the latency is way below 1024. That's with native vst's, windows vst's are another thing. It also assumes there are no hardware issues. I just install the Debian rt kernel and install rtirq-init. The Debian rt kernel can be installed using something like uname -a (to get the current kernel version) then search for kernels using aptitude search linux-image and aptitude search linux-headers and install a similar kernel version that has rt in it's name (linux-image-rt-amd64 and linux-headers-rt-amd64 ) Last edited by osxmidi; 02-22-2019 at 12:28 AM. |
|
01-29-2019, 02:50 AM | #6 |
Human being with feelings
Join Date: Nov 2018
Posts: 63
|
additionally you can try running the kxstudio startup config file.. it does a lot of things already suggested above, but worth a try.
https://kxstudio.linuxaudio.org/Repositories |
01-30-2019, 11:03 AM | #7 |
Human being with feelings
Join Date: Jan 2019
Posts: 17
|
Thanks for the suggestions everybody.
Seems like people's experiences with latency in Linux vary quite a lot. For some, the "low latency" kernel really makes a difference, and for others not. The real time kernels, I've heard, have a lower guaranteed maximum latency but worse average latency than the low latency type, and supposedly more suited for industrial applications, but obviously work for some musicians. |
01-30-2019, 04:01 PM | #8 |
Human being with feelings
Join Date: Mar 2017
Posts: 859
|
Two numeric settings values to insure,
the first in /etc/security/limits.config maximum priority is 99, choose slightly lower to 95 or so if you get any repeatable issues during normal use In qjackctl, the maximum priority is 89, IF you chose 99 in limits.config, lower that proportionately, if you lower the value in limits.config. I use 95 in limits.config and 70 in qjackctl and use a stock Mint 18 kernel with a pci mAudio card. Good luck! the limits.config entry will look something like this, but with spaces between the values @audio rtprio 99 Last edited by 4duhwinnn; 01-30-2019 at 04:08 PM. |
01-31-2019, 04:40 AM | #9 |
Human being with feelings
Join Date: Jan 2019
Posts: 17
|
Thanks for the tip. I recall seeing those settings, but I'll experiment with them if I run into more xruns.
I also realize that before migrating to Reaper, I was using recording techniques that were more plain with no midi tracks, only wav tracks, no instrument plugins, just a few effects, in the DAW. This meant that CPU and soundcard performance requirements weren't quite as high as they are now when I'm doing more processing in the DAW. |
01-31-2019, 08:33 AM | #10 |
Human being with feelings
Join Date: Nov 2018
Posts: 15
|
@ LieMFB:
you're opening the Pandora Box... Look at this (long) thread: https://linuxmusicians.com/viewtopic...9517b14da0a0c5 For me, "low latency" means 128 samples buffer and below. The first tweaks to get the best results are OS independent and begin in the UEFI/BIOS settings of your PC. Don't forget it! Currently, I think a pure Debian distro with RT-kernel (not a "low latency" kernel) should provide the best results. At this time, there is no official guide lines to tweak a Linux OS for best low latency performance. And this is a problem! If you're lucky, you can achieve very good performance without to much tweaks in the OS. The overall result depends on UEFI/BIOS settings, OS type, kernel type, OS config, desktop environment, audio interface, data bus for audio streams (USB, PCI, PCIe, Firewire...), number of tracks in your DAW, virtual instruments or not, number of VST plugins... Thousands of parameters are involved... In my case, I've got better results with Win10. For Win10, I now know that UEFI/BIOS settings were the most important when it comes to low latency. Good luck! |
01-31-2019, 09:39 AM | #11 |
Human being with feelings
Join Date: Nov 2018
Posts: 15
|
As others have told you, be sure to have correctly configured the /etc/security/limits.config file and to add your user to the proper group (it should be "audio" on Debian/Ubuntu, but on Arch it's "realtime"). Try setting periods to 3, on my PC with USB interfaces this works way better than 2. Also, set the Performance governor or anyway raise your CPU frequency up to the top, on macOS this happens automatically when you request a blocked buffer size, on Linux it doesn't.
In my experience Ubuntu and Arch always worked pretty well out of the box with just these settings, but Fedora for istance always performed poorly, I don't know why (I guess nobody uses Fedora for Audio purposes) |
01-31-2019, 11:22 AM | #12 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
I can see how a couple of those might have been relevant to your situation, but in my BIOS they're automatically set that way (XHCI handoff enabled, VT-D disabled) and apparently that's been standard for years. One of the settings (disable io serial port) might have an effect...it's something I do anyway. It makes me wonder what setting in particular helped you, or if it was something else (if you were doing a reformat/reinstall at the time, or changed any other settings). Do you remember which settings you had to change? Please share this information for others, if you know what helped. |
|
02-01-2019, 01:42 AM | #13 |
Human being with feelings
Join Date: Nov 2018
Posts: 15
|
Hey James!
I think I write better in the original forum at linuxmusicians (although I do not use Linux as I originally thought). I don't want to further "pollute" this Linux thread here with my Win10 considerations... So... See you at: https://linuxmusicians.com/viewtopic...7cb90&start=90 I think I will update the thread at linuxmisicians in the coming days/weeks, since the test phase of the DAW workstation is now done. It means that I will reinstall Win10 on a new M2 SSD and activate it. And reinstall everything: drivers, progs, plugins... At this point, it could be interesting to write everything down (install order, type of drivers, settings...). I'm more and more thinking that all the clicks/pops I had in Win10 were related to bad drivers (SATA or so). I've made a Win10 reinstall and tweaked the UEFI/BIOS like for a Mac install. And then, all glitches were gone. Last edited by Nuri; 02-01-2019 at 02:57 AM. |
02-01-2019, 09:24 PM | #14 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
If you changed drivers during all of this, there's no way of knowing what your problem was. It might've been something similar in your Linux install too. There's no way of knowing now.
As a result, I'd recommend to anyone reading this: don't alter settings in your BIOS based on the recommendations for installing MacOS. It probably doesn't have any positive effect. To anyone who posts computer advice, and later learns it may not be accurate: please edit or delete your posts, so you don't mislead others with it. There's plenty of misinformation on the 'net and it's difficult enough to sift through for good information. Please don't contribute to the increase of misinformation. |
02-02-2019, 03:29 AM | #15 |
Human being with feelings
Join Date: Nov 2018
Posts: 15
|
@ JamesPeters
One of my first intentions in the thread at linuxmusicians was also to completely write down all settings related to a particular hardware/software config. As you can see, I'm now experimenting around on my DAW workstation for several months and I think everything should now work as expected, with a playable very low latency for live context. I only have to make the final Win10 install (with activation and updates) and write each setting down. Unfortunately, I had to switched to Win10 as I understood that the other band members want to use our Windows VST plugins. It's mandatory for us! Using linvst or other software bridge is not a valuable solution for us (and I could not manage to install the Waves plugins V9 with wine, it's crashing). And since the Win10 DAW workstation will always be offline, I have personally no problem to use this OS (from a freedom and privacy policy point of view). I'm sorry that I cannot further help setting up a valuable very low latency Linux config. |
Thread Tools | |
Display Modes | |
|
|