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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
