27 Jan
2009
27 Jan
'09
9:18 a.m.
On Tue, Jan 27, 2009 at 1:06 PM, Peder Hedlund <peder(a)musikhuset.org> wrote:
Quoting Ken Restivo <ken(a)restivo.org>rg>:
limits.conf is just to give users access to realtime capabilities. As
I understand it, the rt patch makes changes to the kernel to give
lower realtime speeds through alterations in the way preemption is
handled (my very non-technical understanding). So, they are doing
different things.
That being said, I agree, for normal hobbyist computer music, I have
found a standard debian kernel to give perfectly adequate performance
(of course as long as the user has access to realtime capabilities).
I think it is possible to get a bit obsessional about getting the
lowest possible latency. IIRC I think I read that standard hardware
midi keyboards have a latency of around 10ms, and mechanical organs
can have even more latency?? So, I think it is more a matter of
technique.
With live recording, having a "blip" marker (very technical!! LOL) at
the beginning of each track to line up each recorded track post-hoc
seems to help too, even with very long latencies.
James
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".