[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)
robin at gareus.org
Sat Jan 31 22:42:40 EST 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
>>>> 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.
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!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Linux-audio-tuning