[LAU] Jack vs. Alsa, PianoTeq demo: Alsa wins!

[Paul Davis]

On Tue, Jun 14, 2011 at 3:11 AM, Aaron Krister Johnson
<aaron at akjmusic.com> wrote:
> Hey all,
> So the continuing saga is this: still no luck getting Pianoteq with JACK to
> equal or spank with superiority the performance of PianoTeq w/ALSA alone on
> my system.....
> I found the following information: the info from the /proc/asound output
> that Paul asked me to check out confirmed that at comparable settings, JACK
> choked where ALSA smoked. I had ALSA down to a period of 64 and 3
> periods/buffer (hardware bufsize of 192) at a sample rate of 48000. The same
> setting of jackd ('jackd -dalsa -dhw:0,0 -r48000 -p64 -n3 -S') didn't agree
> with Pianoteq....
> So...here's my dilemma. I have a live show coming up where I'd prefer to use
> the superior harpsichord sound of Pianoteq, but I don't want to risk a
> lock-up or xruns or worse in a live concert. So I would have to use
> ALSA...BUT....I also need to switch to playing a live kalimba through some
> Csound effects right after playing a harpsichord, and Pianoteq under ALSA
> will not stand for another app opening and sharing the soundcard like JACK
> will allow (ALSA will block I/O).
> So what can I do?

only all the usual deeply unpleasant, deeply technical stuff related
to figuring out sources of scheduling latency on your system. as i
mentioned previously, JACK requires that your system can context
switch efficiently and without delay. lots of people (including me)
have systems that have issues with this. its caused by a tangled
thicket of interactions between the motherboard, the PCI bus, the
kernel and some userspace stuff. there is no magic bullet that will
fix a given system.

case in point: i dramatically improved things on my system yesterday
by switching from the open source nouveau driver for my nvidia card to
the proprietary one. i can now run JACK down at -p 64 -n 2 and
dragging windows around or moving the mouse back and forth across the
boundary between two monitors no longer causes gaps in the audio
(which it used to be able to do even without xruns, suggesting PCI bus
issues). but still, after 12 hours of the new system, i still have 654
xruns. this is on a very, very powerful 6-core system but without an
RT kernel.

--p