26 Feb
2005
26 Feb
'05
5:04 p.m.
Hi.
Being quite a newbie to audio on Linux, I am trying to
get rid of xruns when I record using ardour and jackd.
I start jackd with
jackd -d alsa --device hw:1 --rate 44100 --period
8192 --nperiods 2
but this max. buffer size is still not enough to
completely prevent xruns. I see xruns often when I
switch between windows and so thought that this is
caused by Xfree86 stealing CPU from jackd, since
xfree86 runs with nice factor -10.
I tried to run jackd as root so I could use the
"--realtime" option but my system is then sadly
reduced to a thrashing heap of rubble.
After loading a recorded session (approx. 45 minutes
of audio - 830 MB data) "top" tells me that
ardour is using 69.5 %MEM
jackd is using 25.6 %MEM
and the loading of the session has taken several
minutes due to thrashing (kswapd is on heavy work here
according to "top"). The system is very unresponsive
and I am unable to use ardour for anything useful.
If I don't use the "--realtime" option, "top" says
ardour is using 20.4 %MEM
jackd is using 2.1 %MEM
after the session is loaded (in 2-3 seconds), and the
system runs quite well (except for the occasional
xruns of course).
Is "--realtime" forcing jackd and its clients to lock
all of their memory in RAM ? I would then need quite a
lot of RAM to use the "--realtime" option. Is it
really necessary to use _that_ much RAM ?
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 ?
Cheers
-- Jan Holst Jensen, Copenhagen, Denmark
____________________________
System info:
Debian Sarge with a custom-built unpatched kernel
2.6.10. Kernel config includes "Pre-emptible kernel"
and pure ALSA - no OSS emulation.
Compaq Evo N400C laptop. 700 MHz Pentium III with 128
MB RAM. I know this is not top-of-the-pops but I have
used it for two years to do stereo recording and
8-track mixing on Windows 2000 quite nicely.
jackd version:
bonham:~# jackd --version
jackd version 0.99.0 tmpdir /dev/shm protocol 13
bonham:~#
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
26 Feb
26 Feb
5:18 p.m.
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
5:54 p.m.
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. This is the best solution. JACK clients should
I can't start jackd with that option even though I can
see it loud and clear in the man page as you say.
jackd --realtime -d alsa
starts up, but
jackd --realtime --unlock -d alsa
or
jackd --realtime -u -d alsa
says "unknown option character" and jackd outputs a
usage message where both "-u" and "--unlock" are shown
as examples. Huh ?! Is my jackd broken ? I installed
it through apt-get on my Debian Sarge. Version says
0.99.0.
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. 
11:10 p.m.
Jan Holst Jensen <jhje00(a)yahoo.com> writes:
starts up, but
jackd --realtime --unlock -d alsa
or
jackd --realtime -u -d alsa
says "unknown option character" and jackd outputs a
usage message where both "-u" and "--unlock" are shown
as examples. Huh ?! Is my jackd broken ? I installed
it through apt-get on my Debian Sarge. Version says
0.99.0.
I recall a bug in that option a while back, but don't remember exactly
when it was fixed. Maybe after 0.99.0. Try using the -m (--no-mlock)
option.
--
joq
27 Feb
27 Feb
10:48 a.m.
--- Jack O'Quin <joq(a)io.com> wrote:
Hi Jack.
Thanks. A very short test seems to show that I can get
down to 23 msec latency using the -m option on this
laptop while I am browsing the net, and that would be
just fine for me.
I'll try building jackd from source to see if I can
get a working --unlock option. Otherwise I may just
invest in 512 MB RAM for my laptop. Tried jackd and
ardour on a stationary 2.5 GHz Pentium IV with 512 MB
RAM and I could get 3 msec latency without apparent
trouble. Wow!
Cheers
-- Jan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
jackd
--realtime -u -d alsa
says "unknown option character" and jackd outputs
I recall a bug in that option a while back, but
don't remember exactly
when it was fixed. Maybe after 0.99.0. Try using
the -m (--no-mlock) option.
7211
days inactive
7212
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Jack O'Quin -
Jan Holst Jensen -
Lee Revell