jackstart worked for setting the capabilities, but I'm still getting xruns in duplex mode even with the sampling rate set to 44100. On Wed, 21 Jan 2004, Jesse Chappell wrote: > > > 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 > > >
