[LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA? )
nescivi at gmail.com
Tue Mar 10 08:57:04 EDT 2009
On Thursday 29 January 2009 18:41:48 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
> > > 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 have been getting some xruns with my setup.
Using jack with these settings:
/usr/bin/jackd -R -p128 -t200 -dalsa -dhw:0 -r44100 -p1024 -n3
Using the internal soundcard (intel HDA).
Basically running SuperCollider to play a stereo soundfile (the main track for
the dance piece), and do some beattrack and pitchtrack analysis on that.
The rest was mostly creating control signals (but on scsynth) for a light
installation, which was controlled from the serial port.
The other big loads were:
* scgraph (about 15% CPU), for visualisation of what was happening (or should
happen) with the light installation.
* capturing video at 640x480 from a Canopus connected through firewire, using
the vloopback module and dv4l, and feeding it into motiontrackosc, which was
then communicating with SC, through OSC. This whole chain was quite CPU
* SwingOSC for some SuperCollider GUIs.
realtime priorities were handled through limits.conf, and I am running on the
Debian kernel 2.6.26-1-amd64 on a Intel Core2 Duo, T7500 2.20 GHz. (It's a
Lenovo Thinkpad T61).
The previous Debian kernel 2.6.24, did give me better results with JACK, but
had problem with the serial chip driver (the FTDI), at certain baudrates.
So yes, the few xruns were problematic, since my soundtrack was the only sound
that was going on, and I would really like to know how I could make this
whole setup a bit more robust.
The video capturing and the visualisation are certainly less time critical, as
I am only deriving control data from it, and/or using it to monitor. It is
not projected out again.
PS, I may put some video material of this thing online a bit later.
More information about the Linux-audio-user