16 sample buffer with Arch Linux

Optimize your system for ultimate performance.

Moderators: khz, MattKingUSA

merlyn
Established Member
Posts: 709
Joined: Thu Oct 11, 2018 4:13 pm

16 sample buffer with Arch Linux

Post by merlyn »

The imminent end of Ubuntu 14 prompted to me to put a new audio setup together, and I decided to use Arch.

I have been using KX studio for three years on an Athlon II X4 620 system with a Hoontech DSP24 soundcard and an nvidia GTX 650 graphics card. I found KX 14.04.5 to be an improvement over 14.04. It 'felt' better. More solid somehow. The first thing I do is run Cadence and see how low the buffer will go. It was 32 samples. On KX, if I set the buffer to 16, there was immediately a stream of Xruns, even without any DSP load. KX 14.04.5 simply can't do a 16 sample buffer on my system.

So I wondered ... was this a limitation of my soundcard?

I considered that an RT kernel might allow a 16 sample buffer, and tried AV Linux. Unfortunately I couldn't get a definitive answer because I had issues with my graphics card + RT kernel + nouveau drivers, and to get a stable, Xrun free AV setup I had to use nvidia proprietary drivers, which only work with the AV low-latency kernel.

But still it bugged me. What is an RT kernel anyway?

So I installed Arch, thinking that the minimal setup would allow me to see what was going on, and where the issues were. My goal here was 'nothing unnecessary', so I used openbox, and changed system files so it automatically logs in and starts X. Minimally minimal.

I installed the linux-rt-lts kernel, jack2dbus and Cadence and answered my question. My soundcard can do a 16 sample buffer. I have tried Hydrogen with this setup and it plays back without audible Xruns. Cadence does report some, but I don't hear them.

If you are prepared to spend some time on an Arch setup, I would recommend it.

User avatar
bluebell
Established Member
Posts: 1426
Joined: Sat Sep 15, 2012 11:44 am
Location: Saarland & Frankfurt, Germany

Re: 16 sample buffer with Arch Linux

Post by bluebell »

I can use a bufsize of 16 on my Xubuntu 16.04 with a lowlatency kernel – but not on each USB-port. There are USB-ports that need 128.

I use the smaller Focusrite Scarletts (Solo, 2i2, 2i4).
Linux – MOTU UltraLite AVB – Qtractor – https://soundcloud.com/suedwestlicht

User avatar
sysrqer
Established Member
Posts: 1953
Joined: Thu Nov 14, 2013 11:47 pm
Contact:

Re: 16 sample buffer with Arch Linux

Post by sysrqer »

Thanks for expanding on this, it's very interesting.

Yeah that issue with nvidia and RT kernels is annoying. I've seen sadko4u saying that there is a way to make it work but I don't remember the details, I don't have a need for the RT kernel. I'm a bit confused about the kernel install when you tried arch, you had nvidia drivers and installed the RT kernel? That's cool that you can without problems if so.

So where do you think the gain came from? Aside from patches and different choices of compiling options, I find it hard to believe that there is any real difference between most distros when configured in the same way. I actually think that if you want to look in to minimalism and control then arch is a bit of a cop out. Gentoo/funtoo gives you so much more, you can control dependencies in a way that makes arch look like ubuntu (I use neon now by the way, before I get haters on every side). In some ways I don't see the point of arch, for me at least. Depending on your needs, you have to compile a lot of audio stuff to have a well equipped set up and if you need to do all that then a lightweight install of gentoo with features/options carefully chosen would not be too much extra work and it would give you a much more trimmed down system, and, in theory, perform faster because it is optimized for your specific hardware.

What do you do with 16 buffers though, play a midi device in to hydrogen? Do you record it at the same time? I've never even tried, I would say it's an unrealistic target but if you've got it working to the point that it's usable then that's great. I can play guitar through an amp sim at 256 and it's alright although I don't make music where precision in speed is necessary.

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: 16 sample buffer with Arch Linux

Post by asbak »

Nouveau drivers are likely going to increase the xrun count and 16 sample buffer is unrealistic if the idea is not to be entertained by xrunning. With some cards one can get acceptable (very few xruns) results at 64 on a system that's been tuned.

People will say "but I can go to 32 or 16" or whatever. Yes you probably can but not without excessive xrunning once you start driving realistic loads through things. 64 is about as good as it gets for many usage case scenarios (chucking web browser audio at it, routing pulse through jack, using guitar fx, playing softsynths - all at the same time).

What's the point going lower and having the soundcard light up like a geiger counter.

These urban myths that people keep repeating about what magical results Arch produces is also getting tiring. It's the equivalent of these Mac fanatics who engage one another in endless validating each other's feelings discussions about how great everything about Apple is. Arch works just fine but so does every other Linux distro out there once it's been set up properly.

There is nothing special about Arch. Get over it.

User avatar
CrocoDuck
Established Member
Posts: 1108
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: 16 sample buffer with Arch Linux

Post by CrocoDuck »

merlyn wrote:So I installed Arch, thinking that the minimal setup would allow me to see what was going on, and where the issues were. My goal here was 'nothing unnecessary', so I used openbox, and changed system files so it automatically logs in and starts X. Minimally minimal.

I installed the linux-rt-lts kernel, jack2dbus and Cadence and answered my question. My soundcard can do a 16 sample buffer. I have tried Hydrogen with this setup and it plays back without audible Xruns. Cadence does report some, but I don't hear them.

If you are prepared to spend some time on an Arch setup, I would recommend it.
I am on Arch too. I hardly believe there is anything specific to Arch making the whole ordeal to succeed. Build a light weight system and optimize it, and you should pretty much get the very same result regardless that being Debian, or Fedora, or OpenSuse or...

It would be nice for you to report the steps you did to achieve your setup, though. Any configuration tip that you think you should mention?

Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: 16 sample buffer with Arch Linux

Post by Jack Winter »

To use the nvidia driver with a rt patched kernel you need an extra patch to work around a nvidia issue, and you also need to patch the script building the nvidia kernel module as it aborts when it detects a rt kernel. To me it seems it would have been better to fix the issue in the driver, instead of aborting when a rt kernel is detected :)

It's not that Archlinux is better than other distros (except in the eye of the beholder :), but IMO a rt kernel makes xruns less likely, depending on hardware and drivers used. And I suppose that if you can use it a 16 frames buffer without xruns, then they are really unlikely at 64 or 128. At least that's the reason that I personally always try to push things into extremes when testing.

IMO the big difference is that the rt patched kernel lowers thread scheduling latency. Maybe not so important today with SMP/SMT systems, but it still makes a difference. If you need your audio processing thread to finish in 1.5ms, it's no good if it takes 2ms before it starts running..

The good news is that the realtime patchset is scheduled to be included in the vanilla kernel in 2019 or at the latest 2020. That means that it will just be a config option among others, and that nvidia and other drivers will have to work with it. Distros will also have no more excuse not to include a rt kernel in the repos :)

To me the drawback of Gentoo is compiling source for everything.. It does take some time, but as machines get faster I suppose it's less of a problem.

Another advantage of using a really small buffersize, is that the loopback latency added by the USB protocol on Linux is much smaller. The bigger the bufffersize used, the bigger the "hidden" USB latency becomes.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

merlyn
Established Member
Posts: 709
Joined: Thu Oct 11, 2018 4:13 pm

Re: 16 sample buffer with Arch Linux

Post by merlyn »

Thanks for all the replies.
sysrqer wrote:I'm a bit confused about the kernel install when you tried arch, you had nvidia drivers and installed the RT kernel?
I'm using the nouveau drivers on my Arch setup. It was when I tried AV Linux that there were issues with my graphics card.
sysrqer wrote:So where do you think the gain came from?
I think starting with nothing and adding only what is needed has made the system more efficient. Is it the RT kernel? I'll find out. Later I'll boot with the stock kernel and see what that is like. I'll post the results.
sysrqer wrote:What do you do with 16 buffers though, play a midi device in to hydrogen?
I used Hydrogen as a drum machine. I also tried Qsampler for loops and it is playing back without clicks. Those are light loads. The real test will be Ardour, and I'll do that later.

The practicalities of low latencies is a good point. If I am mixing then latency is of no significance whatsoever. Latency and CPU load are inversely proportional. As latency goes down the CPU load goes up. So it is possible to use more plugins by putting the latency up until you start to notice lag when moving controls. Low latencies are good for recording and essential if you want to hear plugins while you are playing. My thinking is the same as Jack Winter's -- if the system can cope with 16, it can cope with 32 more easily.
asbak wrote:There is nothing special about Arch. Get over it.
I'm over it. :D My intention was not to stir up tribalism over 'this distro is better than that distro'. I haven't tried every distribution, so I don't know. My experience is that a standard distribution needs software removed to handle audio well. As an example KX studio disables baloo, which means the search box on the file browser is broken. Baloo is disabled because it can jump in unexpectedly and cause Xruns. Also KX works better with WiFi disabled. Rather than start with a ton of software and remove bits, another approach is to start without problematic software, adding only what is needed. For 'Arch' you can read 'minimal system built from the ground up'.

Cheers. :D

merlyn
Established Member
Posts: 709
Joined: Thu Oct 11, 2018 4:13 pm

Re: 16 sample buffer with Arch Linux

Post by merlyn »

CrocoDuck wrote: It would be nice for you to report the steps you did to achieve your setup, though. Any configuration tip that you think you should mention?
If anyone wants to try this I would suggest keeping a working system and doing this as a dual boot on another drive or partition. It could take a while and it's good to have a system available. I set up a few 20GB partitions as a test bed.

In addition to all the changes recommended by raboof's quick scan script
I edited limits.conf to give my user 99 rt priority.
I put threadirqs in the grub command line
Installed rtirq and edited the configuration file so that the soundcard gets the highest rt prority

It is mysterious to me why an RT kernel did not work with AV linux and did work on Arch. One difference I noticed is that i have microcode installed on Arch, but not on AV. Could that be it? It could be a bug in my processor that microcode fixed. If anyone knows, please share. :D

User avatar
Michael Willis
Established Member
Posts: 1067
Joined: Mon Oct 03, 2016 3:27 pm
Location: Rocky Mountains, North America
Contact:

Re: 16 sample buffer with Arch Linux

Post by Michael Willis »

merlyn wrote:I'm over it. :D
Well done, sir. I wish all disagreements around here could be settled so tactfully.

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: 16 sample buffer with Arch Linux

Post by asbak »

merlyn wrote: I'm over it. :D My intention was not to stir up tribalism over 'this distro is better than that distro'. I haven't tried every distribution, so I don't know. My experience is that a standard distribution needs software removed to handle audio well. As an example KX studio disables baloo, which means the search box on the file browser is broken. Baloo is disabled because it can jump in unexpectedly and cause Xruns. Also KX works better with WiFi disabled. Rather than start with a ton of software and remove bits, another approach is to start without problematic software, adding only what is needed. For 'Arch' you can read 'minimal system built from the ground up'.

Cheers. :D
The KX project is awesome in many ways by virtue of all the lovely audio tools it provides and it is a nice way to get introduced to the Linux audio ecosystem.

But having said all that I don't think that the KX Distro (specifically the distro) is suitable (for me anyway) for general purpose workstation usage and agree with your approach to install a standard distro (such as Arch) and setting up the required audio packages on an as-required basis whilst retaining more control over what is and isn't installed and how things are configured.

On Debian, Ubuntu & Mint, installing the KX overlay makes a number of changes (not fully documented or explained) which may or may not affect how you work.

My 2c, installing individual packages from the KX Studio project makes it possible to keep one's Workstation closer to standard and therefore simpler to understand and manage. That would be a rough equivalent of what you're doing on Arch.

Cheers
:D

asbak
Established Member
Posts: 647
Joined: Thu Sep 11, 2014 3:04 pm

Re: 16 sample buffer with Arch Linux

Post by asbak »

merlyn wrote: It is mysterious to me why an RT kernel did not work with AV linux and did work on Arch. One difference I noticed is that i have microcode installed on Arch, but not on AV. Could that be it? It could be a bug in my processor that microcode fixed. If anyone knows, please share. :D
The kernel is part of the solution to achieve decent low-latency operation but as you already mentioned there are a number of additional things which need setting up. I would have thought that this would have been taken care of already in AV Linux so it is a bit surprising to hear of such inconsistent results.

Unfortunately all it takes is one or two duff settings or a non-intuitive issue elsewhere in the system to ruin overall performance and tracking it down can be a nightmare.

User avatar
CrocoDuck
Established Member
Posts: 1108
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: 16 sample buffer with Arch Linux

Post by CrocoDuck »

merlyn wrote:It is mysterious to me why an RT kernel did not work with AV linux and did work on Arch. One difference I noticed is that i have microcode installed on Arch, but not on AV. Could that be it? It could be a bug in my processor that microcode fixed. If anyone knows, please share.
asbak wrote:Unfortunately all it takes is one or two duff settings or a non-intuitive issue elsewhere in the system to ruin overall performance and tracking it down can be a nightmare.
This. I think it is gonna be very hard, if at all possible, to figure out in details why that is happening. One thing you could try is to compare the kernel configurations and see whether you can spot anything obvious in there.

User avatar
sysrqer
Established Member
Posts: 1953
Joined: Thu Nov 14, 2013 11:47 pm
Contact:

Re: 16 sample buffer with Arch Linux

Post by sysrqer »

merlyn wrote: I'm using the nouveau drivers on my Arch setup. It was when I tried AV Linux that there were issues with my graphics card.
Thanks for the info, definitely food for thought.

Be careful with nouveau, it's not really suitable for audio work and can cause the system to lock up. I've not found anywhere documenting this in much detail but the arch wiki briefly mentions it here https://wiki.archlinux.org/index.php/No ... r_messages and I've seen knowledgeable people here, and the ardour devs, say that it is not recommended and that it is a fairly well known problem. Using nvidia certainly fixed the problem for me.

Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: 16 sample buffer with Arch Linux

Post by Jack Winter »

merlyn wrote:It is mysterious to me why an RT kernel did not work with AV linux and did work on Arch.
Most likely AVL didn't patch the rt kernel to work around a NVIDIA bug. The symptoms are that the system boots into a GUI but the GUI hangs after a short while.

See: https://aur.archlinux.org/cgit/aur.git/ ... h=linux-rt
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

merlyn
Established Member
Posts: 709
Joined: Thu Oct 11, 2018 4:13 pm

Re: 16 sample buffer with Arch Linux

Post by merlyn »

Thanks for all the info. It's informing my approach.
sysrqer wrote:So where do you think the gain came from?
I tired the stock Arch kernel and was shocked to find ... there wasn't much difference. Using the stock kernel and a 16 sample buffer, I maxed out my processor running Hydrogen into Ardour with two plugins on Hydrogen's channel. I wasn't expecting the stock kernel to work at 16 at all. Hydrogen played back on its own fine. I then saved the Ardour project and rebooted with the rt kernel. There may have been slightly less DSP usage, but nothing spectactular.

The gain in question, though, is between my new Arch setup and my old KX setup.

It has been said that art is science with more than six variables. So I have changed too many variables between KX and Arch to pin down where the gain came from.

Smile! Yer all artists!

Post Reply