Keith Parkins wrote on Wed, 21-Jan-2004: > Hi, > > 1) I'm using alsa 1.0.1 with the latest version of jackd on a via kt400 > mobo (VT8377) and a VT8233 audio controller. I have the low-latency/premp > kernel patches as well as the capabilities patch applied to a 2.4.22 > kernel. I get xruns like crazy that average around 0.09 msecs when running > jackd in duplex mode. These disapear when running in either capture or > playback mode. I had seen that there may be some issues with the via82xx > chipset and jackd on the alsa list, but no solutions or description of > what the actual problems were. Am I stuck in a duplex-free zone or is > there a way to work around this? Will this affect my ability to use ardour > as multitracking device using the mic/line-in, or will it only cripple my > ability to use other programs as jack slaves? What sample rate are you using? Try the other one, (48000 or 44100) and see if it's any better. > 2) Even with the capabilities patch, I get the following error when > running jack as a normal user: > > JACK: unable to mlock() port buffers: Operation not permitted > cannot set thread to real-time priority (FIFO/20) (1: Operation not > permitted) > cannot use real-time scheduling (FIFO/10) (1: Operation not permitted) You need to run jackstart, instead of jackd to make use of the capabilities patch. If you haven't been realtime, that might explain your full-duplex overruns too. jlc