On Fri, 2009-01-30 at 03:23 +0100, torbenh(a)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(a)restivo.org>rg>: >>> >>>> 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?

> 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.

On Sun, 01 Feb 2009 04:42:40 +0100 Robin Gareus &lt;robin(a)gareus.org&gt; wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Fernando Lopez-Lezcano wrote: >> On Fri, 2009-01-30 at 03:23 +0100, torbenh(a)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 &lt;ken(a)restivo.org&gt;rg>: >>>>> >>>>>> 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.