10 Mar
2009
10 Mar
'09
9:57 a.m.
Hiho,
On Thursday 29 January 2009 18:41:48 Fernando Lopez-Lezcano wrote:
On Tue, 2009-01-27 at 14:06 +0100, Peder Hedlund
wrote:
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
intensive.
* 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.
sincerely,
Marije
PS, I may put some video material of this thing online a bit later.
Quoting Ken Restivo <ken(a)restivo.org>rg>:
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 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" ?