[linux-audio-user] alsa rme96 jack - 186 msec latency?

[Michael Rudolf]

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 ...