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