15 Jun
2011
15 Jun
'11
10:31 a.m.
Paul Davis wrote:
On Tue, Jun 14, 2011 at 3:11 AM, Aaron Krister
Johnson
<aaron(a)akjmusic.com> wrote:
I can second that one which improved things on my laptop. Sad
as it may
be the binary drivers seem to deliver better general system performance
than the nouveau ones.
Another one I experienced (again working with intensive Pd stuff) was to
ensure that all "CPU scaling" stuff was set to maximum performance and
nothing automatic is going on (such as "Ondemand" et sim.) both CPU-wise
*and* graphics card GPU-wise (this can e.g. be controlled in the
nvidia-panel for the proprietary drivers).
All this, of course, after taking care of the 'usual' real-time
settings. This not only on the jack/audio side: e.g. even if jack is
running realtime with bleeding edge low latency your software may not be
playing well rt (I experienced this with Pure Data were an explicit -rt
command line switch is needed to get smooth rt performance).
Anyway good luck :)
Lorenzo.
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.....[...]
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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user