[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)
hollunder at gmx.at
hollunder at gmx.at
Sun Feb 1 06:08:20 EST 2009
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, 2009-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 184.108.40.206-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 220.127.116.11 #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 18.104.22.168 but I'm not too certain.
I don't even know how to check that reliably.
> Here's my .config running running debian/lenny+sid on a Thinkpad X60s:
> PS. I bumped into Linus at LCA: 2.6.27 still had various issues with
> the "big kernel lock" in some modules - most notably vfat - but they
> should be pretty much gone by now. YAY!
Sounds like good news, thanks.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> -----END PGP SIGNATURE-----
More information about the Linux-audio-tuning