20 Jun
2011
20 Jun
'11
8:15 a.m.
Aaron Krister Johnson wrote:
Hi all,
I just wanted to report that I finally have joy regarding the
Pianoteq/JACK issues I've been plagued by!
What worked for me is disabling 'CPU overload detection' (in
Pianoteq). I had already disabled 'multicore' in the same 'Performance
dialog', and just to be extra sure, I took all of my WIFI connections
offline, as well as unloading the drivers for wireless all together
while I played (in this case, it was 'ndiswrapper'). I don't think it
was causing a problem, but every extra thing that eats CPU or memory
that I don't need while playing doesn't hurt to take offline.
I've heard that wireless drivers can cause many xruns because they
periodically rescan for available wireless connections (even if the
wireless card's external antenna is turned off). When their scan takes
much time, apparently, and they hog things while doing it.
Just FYI, for anyone who can find the information
useful, my setup:
* ASUS EEEPC 1000HE
* Lexicon Lambda outboard USB sound interface, IRQ made RT priority
with 'chrt -p 99 XXXX', XXXX being the process ID of the IRQ handling
the USB sound interface, found with 'cat /proc/interrupts' and 'lsusb'
* Arch Linux, which I recommend over Ubuntu anyday for minimalists who
want to squeeze every last drop of bloat (and thus benefit
performance) out of their boxes.
* output of 'uname -a' : Linux myhost 2.6.33-rt #1 SMP PREEMPT RT Sat
Aug 7 09:40:44 UTC 2010 i686 Intel(R) Atom(TM) CPU N280 @ 1.66GHz
GenuineIntel GNU/Linux
* output of 'jackd -V': jackd version 0.120.2 tmpdir /dev/shm protocol 24
* jackd command: 'jackd -dalsa -r44100 -p128 -n3'
I've heard that many USB interfaces seem to need 3 soft buffer periods
per hardware buffer periods ('-n3' in the jackd command above). I knew
this already, and that wasn't my issue, but I'm just saying this to
other folks who may have problems with outboard USB sound interfaces,
I have to use -n3 with my UCA202.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community