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.
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,
that I've found it to be true in the case of the Lexicon Lambda: it
would choke and bleed xruns on things like '-p256 -n2' but I got as
low as '-p64 -n3', no problem! In this case, since I'm prepping for a
live situation, I'm doubling everything from the lowest possible
latency setting by default for insurance ('-p128' instead of '-p64')
because I can't afford a hard lock or crash in the show....
Thanks again!
AKJ
On Sun, Jun 12, 2011 at 2:40 AM, Aaron Krister Johnson
<aaron@xxxxxxxxxxxx> wrote:
> Hi all--
> I'm wondering if anyone else has experienced this:
> I'm considering purchasing PianoTeq, but I wanted to try the demo. It seems
> to work better with just the alsa driver than it does with jack, a reversal
> of the usual situation.
> I tested this several times by playing fast glissandi on the default piano
> preset. Each time, my little EEE-PC netbook under jack choked with xruns and
> a brief silence while PianoTeq 'reset' itself, but Alsa alone chugged away
> with no xruns unless there was an extreme amount of load....
> I'm wondering if anyone can comment on this. It seems odd, especially since
> the jack developers claim jack adds no latency by itself to the picture in
> any situation---so, do we have a situation where the code is better written
> for the alsa driver than for jackd? It seems we do, in this case....
> Best,
> AKJ
>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
