Do I really need an RT(Real Time) kernel

[logdrum]

I do have a Quad Core i7 running at 3.4 gHz and the maximum 16 GB RAM that my MB can take

I have a generic 11.10 Ubuntu and all I had to do was mess with my pulse and asound.conf plus put a file in /etc/modprobe.d to recognize the old m-audio fast track box. I am happy with the latency I am getting and can run it at 128 frames/period.

I read all about these RT kernels and specialized distros. I heard that Ubuntu studio does not have that much in the way of an RT kernel for the latest 11 versions.

I'd rather stick to Debian type distros...

Do tell about the other distors or does it really matter with the HW that I have.

[GMaq]

Hi,

All kernels since 2.6.39 have the most influential ability (IRQ Threading) of the traditional -RT kernel available as a boot option ('threadirqs') which has eliminated most of the need for full -rt preempt Kernel. By enabling the threadirqs boot option and using Rui Nuno Capela's 'rtirq' script at boot you can achieve latencies equal to a full -rt preempt Kernel and avoid the associated proprietary video driver issues that come with them.

If you use Ubuntu I would guess you can get the rtirq script in a package from the KXStudio PPA's although I'm not 100% sure because I don't use Ubuntu.

Regardless of what you do Kernel-wise if 128 fpp allows you to record and do what you want than it really doesn't matter. Latency is not a gymnastic event... if you can get it low enough to suit your needs as-is then you're good to go.

For the record even specialized Audio distributions are moving away from -RT Kernels. AV Linux uses low-latency custom Kernels with the options above and I believe KX Studio and likely Dream Studio use low-latency Kernels by default as well. There certainly nothing wrong with -RT Kernels they are just not needed by a majority of Linux Audio users right now with the improvements since 2.6.39.

[wolftune]

Thanks for that help. I have a specific question about this:
So I was running Guitarix, and went to relatively low latencies, and the lower ones were really glitchy and the med-low were mostly fine but every now and then had some real glitches (I noticed the RT % then got real high in qJackCtl). I am running KXStudio, but when I installed it, I didn't take the optional step of doing any kernel-related stuff.
So should I try enabling IRQ Threading? And if so, could anyone point me to a specific instruction for setting this up in KXStudio?

Thanks!

[logdrum]

Thanks GMaq. Android as well benefitted from the 3.0 kernel and glad tha it makes no diff in the desktop. I finally intalled my M-Audio Delta Card today and there is no perceivable latency. Maybe if I am multi tracking > 8 sources, I'll look into -rt kernel or just get it in there for good measure.

About Guitarix, I have never experience a race condition in Linux for a while now and guitarix did eat all my memory. I do not know how it happened but I am guessing it was when I still was learning jackd routing and optimizing and restaritng jackd without closing guitarix properly did it.

[GraysonPeddie]

KXStudio does not use a low-latency kernel by default. See Help : Ubuntu : Upgrade, section "Step 5 - Install a Kernel (Optional)."

I've compiled my own custom kernel and I'm running Linux 3.2.11 with a realtime patch. Otherwise, Cadence (part of KXStudio) will mark the generic kernel with an X. I have a kernel with a realtime patch with a yellow warning triangle/"!" symbol.

[wolftune]

So ought I do something regarding the kernel? I have the impression that I do not want to return to an older overall kernel. I think there are reasons to stay with the newer kernels (like you mention 3.2.11. I don't care about getting true RT if it isn't needed, I just want to function with low-latency. So does that mean engaging IRQ Threading with a script? Or should I do some custom kernel like you? Or what? (I'd like to aim for the simplest and least risky solution to start with, but I do want a functional result)

Thanks!

[GraysonPeddie]

You can get Linux kernel 3.2 by getting a PPA from here: http://freshtutorial.com/upgrade-to-lin ... 11-10-ppa/

I don't recommend compiling a kernel unless you know what you're doing.

[wolftune]

Ok, but ought I upgrade to 3.2 (or I guess I hear that 3.3 is about out…)? Are there risks (more than other types of upgrades/installs)?
And how does this relate to the IRQ threading and latency issues?

[Pablo]

Ok, but ought I upgrade to 3.2 (or I guess I hear that 3.3 is about out…)? Are there risks (more than other types of upgrades/installs)?
And how does this relate to the IRQ threading and latency issues?

Roughly, you can install one (or even more than one, but you can't use them at the same time, of course) of three kinds of precompiled kernels.

- Generic (not tweaked for audio work but not so bad)
- Low latency (specially configured kernel)
- RT-patched (very special, not available for all kernel version numbers)

Before 2.6.39 version of the Linux kernel, you could only do irqthreading with a RT-patched kernel. I think that irqthreading was the most important reason why a musician would prefer a rt-patched kernel over a generic or a low-latency one. Fortunately, as GMaq pointed out, from 2.6.39, (this is at the time of this writing: 2.6.39, 3.0, 3.1 and 3.2) you can do irqthreading even with a generic kernel.

IMO, the best option nowadays is a low-latency kernel (that you can install from KXstudio) with irqthreading enabled. Don't worry too much about the exact version number. Either 3.0, 3.1, or 3.2 is good. 3.3 is about out upstream but distros lag behind. Stick to your distro's kernels.

If you install another kernel, grub, the boot manager will know and you will be given the choice at boot time. Run "uname -a", or shorter, "uname -r", to learn which kernel you are running at the moment.

Irqthreading is a good thing but it is difficult to tell you how good, because it depends a lot on your particular hardware.

Finally, we said you can do irqthreading with a modern kernel but note that:

1) It is not enabled by default.
2) You should know how to take advantage of this feature. rtirq-init script is the way to go (Just apt-get install it).

[wolftune]

So, let me see if I have this straight…

I should run:
sudo apt-get install kxstudio-kernel-lowlatency

(and that will be v3 at least, right?)

And then I should run:
sudo apt-get install rtirq-init

Or is that redundant from getting the kxstudio lowlatency option?

And then anything else? Just restart the system? Anything else needed to make the rtirq script run automatically or something?

Thanks for the help. I'm still a newbie…

[Pablo]

sudo apt-get install kxstudio-kernel-lowlatency

I don't know. I suggest you use the search function of your favourite package manager. apt-get is fast if you know the name of the package. Not so fast if you don't.

And then I should run:
sudo apt-get install rtirq-init
Or is that redundant from getting the kxstudio lowlatency option?

In any case, it doesn't hurt if you try to install a package that you had already installed. You will get a message " this package is already in the last version" or something of the sort.

To enable irqthreading, edit the file /etc/default/grub as administrator and search for the line:

GRUB_CMDLINE_LINUX=""

and change it to:

GRUB_CMDLINE_LINUX="threadirqs"

Save and close. And then run this command:

sudo update-grub

And reboot the computer.

rtirq-init has a configuration file, /etc/default/rtirq where you set the hw priorities. It depends on your hardware but the default conf is usually good. There is a forum thread with useful info in Rui's site, rncbc.org (Rui is the person who wrote the rtirq-init script, and qjackctl, qsynth, qtractor...).

Cheers, Pablo

[wolftune]

Ok, the thing I mentioned (kxstudio-kernel-lowlatency) is listed on the kxstudio site, but it doesn't show up in any package manager. The generic kernels do, but I already have a generic pae kernel.

So I still don't understand how to (or whether I should) install some low-latency kernel besides the generic pae v3 that I have.

But I did the IRQ stuff you mentioned. Thanks. I think it helped. I got less xruns (or maybe what I got was lower latency at higher buffer levels? I'm not sure). I'd still like to be able to maximize the low-latency live processing and avoid xruns as much as possible, so if something else with the kernel will help, I'd like to know.

Thanks

[slowpick]

htop shows how your system is distributing cpu load, its at the upper left,
so you can shrink the window, load crucial apps, and monitor how well
the loads are shared.

http://liquorix.net/ this rt kernel has a good reputation. You could set up a
usbstick install, and test it there. Rt makes a more noticable difference,
the closer you get to setting your computer on fire via cpu overheating.

Has some lady burned her knees on an ipad3.xxx yet?

[wolftune]

I can view system activity through the system load viewer, and anyway I was just doing some minor stuff, playing through a reverb effect and nothing else, Catia shows DSP load at less than 20% even though I had the buffer down to 128 (also tried 256 for a while)… But while everything worked mostly, there were still times when bunches of xruns occurred. I was definitely not overloading the DSP or overall CPU. The computer wasn't getting hot either.

So at this point, while I'd consider trying a new kernel (though that link is far from adequate to make me feel informed enough to decide anything), what I really want is to understand why the xruns are occurring randomly even with minor system load. If I can get rid of those xruns so that they only occur when I'm actually pushing the CPU limit, then I can live with that. I don't need to push the CPU limit at this point. I just want to be able to do anything at all, just simple like a reverb and nothing more, with low latency and no xruns.

[Pablo]

First I would check if the audio card is sharing IRQ number with another device.

As an example, this is my /proc/interrupts file:

Code: Select all

$ cat /proc/interrupts
           CPU0       CPU1       
  0:         55          0   IO-APIC-edge      timer
  1:          2          0   IO-APIC-edge      i8042
  4:          3          0   IO-APIC-edge   
  6:         39          0   IO-APIC-edge      floppy
  7:          0          0   IO-APIC-edge      parport0
  8:          1          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          4          0   IO-APIC-edge      i8042
 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3, ahci
 17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4, pata_jmicron
 18:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb7
 19:      92031          0   IO-APIC-fasteoi   ata_piix, ata_piix, uhci_hcd:usb6
 22:        890          0   IO-APIC-fasteoi   ICE1712
 23:       4730          0   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb5, firewire_ohci
 44:      76499          0   PCI-MSI-edge      eth0
 45:         65          0   PCI-MSI-edge      hda_intel
 46:     831490          0   PCI-MSI-edge      fglrx[0]@PCI:1:0:0
NMI:          0          0   Non-maskable interrupts
LOC:     894378     774700   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:       6816       7691   Rescheduling interrupts
CAL:       1291       1301   Function call interrupts
TLB:       4334       4047   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:         13         13   Machine check polls
ERR:          0

I am happy because my m-audio 2496 PCI is alone in IRQ number 22. See "ICE1712". It is so identified because the kernel module for it is "snd-ice1712". I know this if I type in a terminal "cat /proc/asound/modules". Check your case.

In adittion to this, the most relevant part of my /etc/default/rtirq file reads:

Code: Select all

# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc ICE1712"

If you change the default list, in order to activate the new configuration without rebooting the computer run:

Code: Select all

$ sudo /etc/init.d/rtirq start

To see what's happening, I strongly recommend you use htop, an interactive process viewer. Install as usual, launch it in a terminal window:

Code: Select all

$ htop

Set it up like this:

F2: Setup --> Display Options : Make sure "Hide kernel threads" is not ticked -- F10: Done
F6: Sort by --> Sort by: PRI

Now, if you are running a kernel >= 2.6.39 (generic or low-latency) with threadirqs you should see the priorities from top to bottom. You want the audio card priority higher than other IRQ threads and, just below the audio card, the jackd realtime process. At least this is the idea I got from reading Rui and others.

Especially if your audio card does share IRQ number with another hw device which you can't disable it, irqthreading and the rtirq script are your best friends.

HTH, Pablo