[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

Mon Feb 2 13:35:43 EST 2009

On Mon, 2009-02-02 at 09:53 +0100, Lars-Erik Helander wrote:
> I really appreciate the information provided in this thread. However I
> would appreciate if someone could provide a link to some basic
> information on the subject since I have found very little information
> about using standard kernel features for low-latency.
> 
> The kind of questions I do have are:
> 
>   - What kernel versions are suitable to use (have significant
> real-time like characteristics) without applying the rt-patches (...,
> 2.6.25.*, 2.6.26.*, 2.6.27.*, 2.6.28.*)

Users are posting success with 2.6.28.*

>     (Information on what, in this context, was added in different
> versions would of course help)?
>   - If I take some standard distribution which has a suitable (non-RT)
> kernel version, what do I have to do in order to to have some basic
> audio apps running nicely?
>   - Will "rtirq" make a difference on a non-RT-patched kernel system?

No AFAIK. Non-rt patched kernels do not have irq processes running as
separate SCHED_FIFO threads (which is what is tuned by rtirq). 

>   - Do I have to use PAM to have non-root users to acquire necessary rtprios?

I guess it depends on the distro. In most (all?) you have to make sure
the user is allowed to use SCHED_FIFO and lock memory
in /etc/security/limits.conf. That may be already done by your distro -
in some cases you have to add your user to a group for things to work
(and then logout and login again). 

>   - What jackd settings are important?

Depends a bit on the soundcard. 
-R --> to use SCHED_FIFO
-d --> point to your hardware device (ie: hw:0 for the first card)
-p --> say, 128, for low latency
-n --> some hda-intel cards on not so new kernels may need 3 or more

>   - Do I need to assign rtprios explicitly to all my processes
> (qjackctl, qsynth, ...) or is that "automagic"?

Automagic. Jackd gives the proper priority to the clients (to the thread
of the client that handles audio i/o)

>   - Do I need to modify anything else under /sys or /proc for the
> system to use the available rt-like characteristics?

Hmmm, I did not have to but apparently newer kernels need some tweaking
(see other messages in this thread)

> I have close to 30 years experience in developing realtime systems and
> has been using Linux for audio in various distribution the last two
> years. Further I have built RT-kernel for couple of distributions
> (this weekend I successfully built and ran a 2.6.28-rt kernel from the
> new git tree :) ). 

Ah, I have not tried this yet! How did that work out? Any errors or
problems on boot? How exactly did you go about building the whole thing?

> However I have no experience in using newer non-RT
> kernels but I am very interested to find out how well you can have
> them work, especially since whenever you find a nice distro you can
> not use it because the hazzle of building an RT-kernel for that
> particular distro is so big :(.

Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/) has rt
patched kernels of the 2.6.26.8* flavor for fc9 (in the "testing"
repository) and fc10, and should be easy to install (not an objective
assessment, I created and maintain Planet CCRMA :-). 

There are many other distros out there that have rt kernels as well. 

-- Fernando

> Any knowledge or link that would enlighten me are highly appreciated.
> 
> Kind Regards
> 
> /Lars
> 
> 2009/2/2 Robin Gareus <robin at gareus.org>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > krgn wrote:
> >> On Sun, Feb 1, 2009 at 3:08 AM, <hollunder at gmx.at> wrote:
> >>
> >>> On Sun, 01 Feb 2009 04:42:40 +0100
> >>> Robin Gareus <robin at gareus.org> wrote:
> >>>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Fernando Lopez-Lezcano wrote:
> >>>>> On Fri, 2009-01-30 at 03:23 +0100, torbenh at gmx.de wrote:
> >>>>>> On Thu, Jan 29, 2009 at 03:41:48PM -0800, Fernando Lopez-Lezcano
> >>>>>> wrote:
> >>>>>>> On Tue, 209-01-27 at 14:06 +0100, Peder Hedlund wrote:
> >>>>>>>> Quoting Ken Restivo <ken at restivo.org>:
> >>>>>>>>
> >>>>>>>>> And here is the next installment in the saga of trying to get
> >>>>>>>>> Ingo RT going on my Asus EEE.
> >>>>>>>>>
> >>>>>>>>> I successfully built and ran the 2.6.26.8-rt12 with the
> >>>>>>>>> alsa_seq patch. It ran.
> >>>>>>>>>
> >>>>>>>>> The problem is that neither the Ethernet (atl1e) or wireless
> >>>>>>>>> (rt2860sta) work. So I pretty much had to reboot back out of
> >>>>>>>>> it immediately.
> >>>>>>>> I've been running the standard kernel from openSUSE 11.0 on my
> >>>>>>>> Athlon 2000+ and can get down to at least 5.3ms latency on an
> >>>>>>>> Audiophile 2496 using the limits.conf "trick".
> >>>>>>>>
> >>>>>>>> Do people really need lower latencies for music purposes or are
> >>>>>>>> we just thinking "well, I needed the RT patch three years ago; I
> >>>>>>>> ain't stopping now" ?
> >>>>>>> It depends on your usage (this question seems to come up every
> >>>>>>> couple of months lately). The current kernels are much better in
> >>>>>>> low latency applications than three years ago. They are usable if
> >>>>>>> you don't require "low" latencies (64 or 128 x 2). What you get
> >>>>>>> also strongly depends on the hardware mix you have.
> >>>>>>>
> >>>>>>> If you want to use 64 or 128 frame periods (or less) you probably
> >>>>>>> will need at rt patched kernel in most cases. Then again if an
> >>>>>>> occasional xrun is not a problem then you would be fine with the
> >>>>>>> stock kernel.
> >>>>>> i am running with -p64 -n3 on an intel-hda with 2.6.28
> >>>>>> of course internal cards have the greatest potential for
> >>>>>> lowlatencies. so this might be unfair, compared to pci.
> >>>>> Hmmm, I'm not sure, the load on pci itself by a soundcard should be
> >>>>> nothing really hard. What would the internal card use? Would not
> >>>>> that be pci or pci express anyway?
> >>>>>
> >>>> surely they are.
> >>>>
> >>>> $ lspci  | grep Audio
> >>>> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
> >>>> Definition Audio Controller (rev 02)
> >>>>
> >>>> The RT patch does two things:
> >>>> It allows to prioritize interrupts and it [almost] guarantees
> >>>> real-time scheduling for a dedicated process or thread.
> >>>>
> >>>> While the soundcard is low bandwith on the PCI bus, IRQ prio may still
> >>>> be required to override HDD and [sometimes] graphics I/O; at least
> >>>> when playing or recording many tracks. NTL, you can get a perfect
> >>>> x-run free system without the RT patch; you can just not rely on it
> >>>> to be as x-run free as a RT patched kernel ;)
> >>>>
> >>>>>> and i havent really seen xruns which i could not relate to some
> >>>>>> programm which wasnt RT-safe, and i am compiling stuff most of the
> >>>>>> day... though perhaps i am not pushing the DSP load hard enough.
> >>>>>>
> >>>>>> i did not even turn preemptible RCU on.
> >>>>>> the latency measurement instrumentation is also in 2.6.28 btw.
> >>>>> Well, that's very good news then!
> >>>>>
> >>>>> I think the last time I tried to use a non-preempt was 2.6.27.x
> >>>>> (maybe, I would have to double check). Playing 24 channels in
> >>>>> ardour would result in xruns, not very often but they would happen,
> >>>>> this is with 128x2 on an RME hdsp card runing on a quad core intel
> >>>>> system. I should try again with the latest available.
> >>>> I just booted into a vanilla 2.6.28.2 #1 SMP PREEMPT
> >>>>
> >>>> right, there's no realtime patch, yet running jackd at 64 * 3 @48kSPS
> >>>> on a HDA - ardour2 with 12 tracks, a couple of LADSPA effects and
> >>>> jamin (lots of CPU!) - there's no xruns yet!
> >>>>
> >>>> I'll be back in the studio in two weeks from now to test it with USB
> >>>> and 1394 devices. With <=2.6.24 kernels those were always working more
> >>>> reliably that the HDA so I don't expect problems there.
> >>>>
> >>>> BTW. with 2.6.28 I needed to
> >>>>
> >>>>  `echo -1 > /proc/sys/kernel/sched_rt_runtime_us`
> >>>>
> >>>> or edit /etc/sysctl.conf and add
> >>>>   sys.kernel.sched_rt_runtime_us = -1
> >>>>
> >>>> before JACK was able to acquire real-time privileges.
> >>> May I ask what that does? This value is 950000 on my system.
> >>> I think jack has rt privileges here on 2.6.28.2 but I'm not too certain.
> >>> I don't even know how to check that reliably.
> >>>
> >>
> >> jackd would not start with -R if realtime permission can not be granted. I
> >> think you would know if there was a problem ;)
> >> I have to say I don't know either what this option is you are setting,
> >> Robin. Is that the granularity of the timer (in u-sec's)? Setting to -1
> >> seems to suggest that the highest possible value is used, although I'm only
> >> wildly guessing. Would be great to know!
> >
> > indeed, jackd did not start unless run as root or until I changed
> > /proc/sys/kernel/sched_rt_runtime_us
> >
> > It's the us (or .001% of CPU usage?!) above which FIFO and RR will be
> > throttled to recover from a run-away rt process. - I'm not exactly sure
> > why it affects jackd when run as "normal" user; maybe because with CPU
> > load above the default 95% rt can not be guaranteed.
> >
> > There's a bit [off topic] but enlightening info at
> > http://kerneltrap.org/mailarchive/linux-kernel/2008/8/16/2960524
> >
> > BTW. in sysctl.conf it's  not "sys.kernel..." but
> >  kernel.sched_rt_runtime_us = -1
> >
> > robin
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAkmGZ1AACgkQeVUk8U+VK0JleACdGtXQ+jNwHFTkAIsHlN2Lo0+t
> > 7CYAnRHWNCxkQ3CtuvmhLteUH+E6RXNJ
> > =q9dt
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Linux-audio-tuning mailing list
> > Linux-audio-tuning at lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-tuning
> >
> _______________________________________________
> Linux-audio-tuning mailing list
> Linux-audio-tuning at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-tuning