-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Lopez-Lezcano wrote: > On Fri, 2009-01-30 at 03:23 +0100, torbenh@xxxxxx 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@xxxxxxxxxxx>: >>>> >>>>> 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. Here's my .config running running debian/lenny+sid on a Thinkpad X60s: http://mir.dnsalias.com/_media/wiki/kernel/config-2.6.28.2.txt robin 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) iEYEARECAAYFAkmFGjAACgkQeVUk8U+VK0LVngCgt3l+6PXmL5e7cDi5u4Eo05wP U/oAnA/q9PzfzgeIJcn3IcKworS6bzC3 =oUdC -----END PGP SIGNATURE----- _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
