2 Feb
2012
2 Feb
'12
11:47 p.m.
As we know now, the shared IRQs were not causing the xruns.
Just to make sure, everyone's up to date:
-using 2 Delta 1010s together.
-Core2duo E4500
-Ubuntustudio 10.04
-kxstudio repos
-jackdmp 1.9.9. from svn
-The cards are hardware synced via S-PDIF.
In envy24control, a mixer program that knows about these features, hw:0
is set to internal clock and hw:1 is set to S-PDIF.
-using a real S-PDIF cable and not
just an audio RCA cable.
-use .asoundrc.
-cat /proc/asound/cards finds both.
-onboard sound card disabled.
-I know which device represents which hardware card. Thus S-PDIF
direction is correct (re-checked 5 min ago).
-use QJackCtl: /usr/bin/jackd -P89 -v -dalsa -r48000 -p256 -n4 -m -D
-Cmulti_capture -Pmulti_playback
-other frames/period, Priority etc. settings don't help.
-tried on 2.6.33.xx-realtime and 2.6.31.yy-rt kernels.
-in QjackCtl xruns=x(y);
y is growing rapidly (~300/gui update).
I found out, that y represents the xruns reported by jack api, while x
is scraped from the logs. So y are real xruns.
-jack is running with rt priority.
-in limits.conf audio group has unlimited memory, is -20 nice and has 89
rtprio.
interesting side effect:
on 2.6.32-27-generic, the xruns don't occur so often.
with-p512 there's even no xruns.
What's going on there?
Kernel issue?
-p512 is a little too much latency.
Why is a generic kernel xrunning less than a realtime or rt?
jack 1.9.9 compatibility issue?
/mn0