6 Sep
2005
6 Sep
'05
9:36 p.m.
I bought an RME Digi96/8 PST because it was said to have good Linux support
and very low latency, therefore perfectly suitable for hd-recording and
the like.
It's driven by the alsa rme96 driver, and right now I'm configuring it for
use with jack. Only to realize that it can only be set to either 1024
frames and 8 periods or 256 frames and 32 periods, resulting in a
calculated latency of 186 msec either way (displayed by qjackctl). Strikes
me. Isn't that absolutely unacceptable for hd-recording use?
This information is confirmed by the corresponding alsa documentation at
http://alsa.opensrc.org/rme96 .
There is a small note on that page that leaves some hope; it's
basically saying that in jack versions > 0.99.0, I could "create" e.g. 32
periods, but "use" much less, "resulting in much lower latency".
Therefore
I'm now using jack 0.100.1 with Kernel 2.6.12 and alsa 1.0.9b. Still the
only two working configurations are 1024/8 and 256/32; when I try to
reduce periods, I get lots of errors like this (detailed output attached
at the end of the mail):
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...
Any ideas about how to obtain a working low latency configuration? Or do I
have to dump the card? Anyone here using that card in a hd-recording
setup?
Cheers
Michael
Detailed output (-p 256 -n 32 works):
$ jackd -R -P 5 -t 2000 -u -d alsa -P -r 44100 -p 256 -n 8 -m -H -M
jackd 0.100.1
[snipped copyright notice]
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|-|256|8|44100|0|0|hwmon|hwmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 256 frames, buffer = 8 periods
nperiods = 32 for playback
too many consecutive interrupt delays ... engine pausing
cycle execution failure, exiting
DRIVER NT: could not run driver cycle
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...
delay of 139318.000 usecs exceeds estimated spare time of 5769.000;
restart ...