LinuxMusicians

What are your experiences using normal Linux kernels with the threadirqs parameter versus realtime patched kernels? Is there a significant difference in the minimum latency you can use? Any differences in reliability of the audio stream (clicks and pops)? Any difference in overall system stability? I've been using the normal Fedora kernel with the threadirqs parameter on my laptop lately and it works great after setting my USB sound card to a higher IRQ priority. In my experience, the RT patched kernel is unstable and occasionally freezes during normal desktop use.

I'm considering switching Crossfade GNU/Linux to the normal Fedora kernel with the threadirqs parameter because it gets updated more frequently and is signed with a Microsoft approved key so it works with Secure Boot enabled.

I'm using kernel with threadirqs and must say it's working, with kernel 4.0 I have got few xruns ( I have used wifi and all stuff), now with kernel 4.1 system looks more stable.
artek

Be. wrote:I've been using the normal […] kernel with the threadirqs parameter on my laptop lately and it works great after setting my USB sound card to a higher IRQ priority. In my experience, the RT patched kernel is unstable and occasionally freezes during normal desktop use.

I have the same experience (except I don't use Fedora). The RT kernel was definitely more pain than gain.
Now I'm using a manually configured Gentoo kernel (no fancy patches, pretty close to vanilla) and it works like a charm.

artek wrote:I'm using kernel with threadirqs and must say it's working, with kernel 4.0 I have got few xruns ( I have used wifi and all stuff), now with kernel 4.1 system looks more stable.

I'm using the rt-kernel versions now exclusively for more then 9 years. Truly, some versions of them gime trouble, and then I stay with the latest working version. But, to be honest, I've got the same trouble with vanilla kernels of this versions, which I installed for comparison. I'm never ever experience "instability" problems with rt-kernels which aren't introduced by kernel.org vanilla kernel. Well, sure, it happens, but, it's negotiable and get solved real, real fast.

However, I can't comment on any performance boost, as I never used vanilla kernel for more then compare stability.

rt-kernel here as well. Sticking at the moment with 3.18-RT on Arch which is considered stable/LTS, but the difference is indeed not as dramatic as it used to be.
I plan to do another comparison with 4.1 (I found also that 4.0, rt or vanilla was more pain than gain).

Update: I just gave a try at the stock Arch kernel (4.1.6 at the time of writing) with threadirqs + rtirq, and it's perfectly capable of reaching low latencies (64*3 period @96K with a F. Scarlett 2i2). Still got some xruns, but I was quite surprised...
So I'd say the difference between stock and RT is not really noticeable with 4.1.x.
This being said, I still get a slightly better performance out of an older 3.18-RT kernel than any 4.X, RT or not.

Hope this helps,

LX

I have been told the rt is more important with usb devices; might be worth bearing that in mind with testing. What system says the latency is and the xruns you get in certain scenarios are two different things.

With my actual setup, Compaq Presario CQ61 + ArchBang + Focusrite Scarlett 2i4, I can hardly do stuff without RT (RT LTS from Archaudio repos). However, my laptop has always been a pain with USB audio devices...

Be. wrote:What are your experiences using normal Linux kernels with the threadirqs parameter versus realtime patched kernels? Is there a significant difference in the minimum latency you can use? Any differences in reliability of the audio stream (clicks and pops)? Any difference in overall system stability? I've been using the normal Fedora kernel with the threadirqs parameter on my laptop lately and it works great after setting my USB sound card to a higher IRQ priority. In my experience, the RT patched kernel is unstable and occasionally freezes during normal desktop use.

I'm considering switching Crossfade GNU/Linux to the normal Fedora kernel with the threadirqs parameter because it gets updated more frequently and is signed with a Microsoft approved key so it works with Secure Boot enabled.

My experience with "normal" Linux kernels is that they don't work well for audio either with or without tricks & tuning like threadirqs. Particularly not if you intend to use low-latency soundcard settings in jack. It'll xrun like a mf.

The only real solution I've found (perhaps mileage varies for others) is through the use of a PREEMPT (PREEMPT, 1000Hz) or RT Kernel. None of the other fixes or solutions quite managed to work for me, even if they may / may not be somewhat beneficial under particular conditions. (I think Ubuntu provides a kind PREEMPT kernel called "low latency".... I prefer to compile my own).

Another source of xruns (in my case) was opensource nouveau drivers, particularly when using a webbrowser. (Yes I know... supposedly one shouldn't use a browser whilst doing audio but it xruns a hell of a lot less with nVidia drivers)

Certain audio geared distros probably already contain RT or PREEMPT/Low Latency kernels. If RT Kernels don't work for you (and they can sometimes be finicky to get to work problemfree) then compiling a PREEMPT kernel would be the other option. That's what I use most of the time.

I did some changes here and I *think* I am using kernel with threadirqs now. I'm not sure. How do I find out?

There's a boot parameter to activate, so you would probably know it if it was enabled.
I don't remember very well but you may also see the threads in a task manager/top/htop/whatever (or with rtirq.sh status),

With GRUB that would look something like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs"

To experience any tangible benefit for audio work, I assume you need also rtirq (http://alsa.opensrc.org/Rtirq) and to tweak the default configuration for your particular soundcard type.

I followed these instructions exactly:

https://wiki.ubuntu.com/UbuntuStudio/rtirq

But then update-grub failed at first for slightly complicated reasons... then it updated, but I don't know if the changes were applied. You never know with computers.

update-grub overwrites /boot/grub/grub.cfg, so you could first check if threadirqs made it there (which would indicate that the command was successful).

or, on the boot menu, just press "e" to see what is appended to the boot parameters.

Once booted, the simplest is probably to read the output of rtirq status

Or you can run the command below from http://wiki.linuxaudio.org/wiki/system_configuration This should tell you if the kernel you're running is preemptible and has irq threading activated.

You sound quite knowledgeable about this so maybe you can solve the "complicated" part of my uncertainty.

I edited /etc/default/grub and updated grub. However, grub initially complained that it could not find /boot/grub/grub.cfg. Upon inspection, I found that I didn't have the /boot/grub directory. I had /boot/boot/grub. Weird, isn't it?

I have /boot mounted on its own partition. That probably explains it, but I'm not sure if and how.

Well, I copied /boot/boot/grub over to /boot/grub and update-grub worked, but... How have I been booting all this time? Which grub configuration has been read at boot time for the last few months, after I migrated to Debian Jessie?

gimmeapill wrote:

Code: Select all

grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT=y" /boot/config-`uname -r`

I tried it and got CONFIG_IRQ_FORCED_THREADING=y, but the question remains: does it matter to a system that is probably booting off /boot/boot/grub?

I guess I'll have to press e on the grub boot screen to be sure. I can't reboot right now, I am working and have too much going on.

Maybe you have a UEFI system. Do you have /boot/efi?