On Sat, 2005-02-26 at 13:04 -0800, Jan Holst Jensen wrote:
> Is "--realtime" forcing jackd and its clients to lock
> all of their memory in RAM ?
Yes.
> I would then need quite a
> lot of RAM to use the "--realtime" option. Is it
> really necessary to use _that_ much RAM ?
>
No. Try running jackd with the --unlock option. From the man page:
-u, --unlock
Unlock libraries GTK+, QT, FLTK, Wine.
This is the best solution. JACK clients should never use GTK+, QT, or
FLTK in the audio thread anyway, so this will not bother correctly
written JACK clients.
If this does not help, try this:
-m, --no-mlock
Do not attempt to lock memory, even if --realtime.
This will obviously increase the change of xruns, because now a page
fault in the process() callback is possible.
For more information see "man jackd".
> I also tried to renice jackd with -20 so it runs with
> priority 0. Will the "--realtime" option give me
> better stability than the renicing ?
>
Yes, absolutely. Renicing JACK is the wrong way, because it's still
subject to dynamic priority adjustment by the scheduler.
Lee
Received on Sun Feb 27 00:15:20 2005
This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 00:15:21 EET