31 Jan
2009
31 Jan
'09
10:42 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Lopez-Lezcano wrote:
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!
On Fri, 2009-01-30 at 03:23 +0100, torbenh(a)gmx.de
wrote:
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 ;)
On Thu, Jan 29, 2009 at 03:41:48PM -0800,
Fernando Lopez-Lezcano wrote:
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?
On Tue, 2009-01-27 at 14:06 +0100, Peder Hedlund
wrote:
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. 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. 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. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmFGjAACgkQeVUk8U+VK0LVngCgt3l+6PXmL5e7cDi5u4Eo05wP
U/oAnA/q9PzfzgeIJcn3IcKworS6bzC3
=oUdC
-----END PGP SIGNATURE-----