Topic: Bad performance with JACK in Linux

Hi,

I hope the developers are listening....with Pianoteq, I've experienced what is usually the reverse situation in most sound applications under Linux: better performance with ALSA alone than with the JACK low-latency server.

This is *extremely* frustrating to me, I've spent at least 6 hours now trying to configure my system to use ALSA alone for an upcoming performance, for which I specifically bought Pianoteq. However, PianoTeq doesn't play nice with ALSA's "dmix" plugin, grabbing and holding the soundcard, and blocking any other apps from streaming audio to the soundcard. I need to be able to move quickly from one sound to another in this show, performing piano and harpsichord under PT, then playing a wav file, etc.

So, my situation is: PT performs nearly flawlessly under ALSA w/o JACK, but terribly with JACK, producing a horribly broken and xrun-ridden sound.

Apparently, if the developers had programmed PT to use ALSA in the standard way, using the "dmix" plugin instead of JACK would have worked. But right now, no joy.

Has anyone experienced this?

I feel like I've been ripped off: this is supposed to be a flawless piece of software, and I paid good money for it. Maybe I can ask for a refund and just go back to using samples for now

AKJ

Re: Bad performance with JACK in Linux

Hi Aaron,

You did not give enough informations about your setup: cpu type, jack version, jack configuration (buffer size, sample rate, number of frames/period), and your Linux distribution. Also make sure that you have followed the "README_LINUX.txt" recommandations (especially those regarding cpu-freq and real-time priviledges)

If you are using jackd 2.x I would recommand to try jackd 1.x instead and see if there is less xruns -- especially on ubuntu 11.04.

Check the audio load curve in the pianoteq options / perf panel , is it relatively smooth or spiky (a screenshot would help, feel free to send it to http://www.pianoteq.com/support_form?direct )

Have you checked this thread: http://www.forum-pianoteq.com/viewtopic.php?id=1927 ? In that case the solution was to disable the wifi.

Re: Bad performance with JACK in Linux

Hi Julien,

I *really* appreciate the prompt reply!

Finally, some joy in my situation! PianoTeq is performing beautifully and not choking anymore; performance is as good as ALSA alone right now, it seems!

What worked for me is disabling 'CPU overload detection'. 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