Subject: Re: [linux-audio-user] rezound as jack client
From: Malcolm Baldridge (linux-audio_AT_paypc.com)
Date: Sat May 01 2004 - 04:27:16 EEST
> Thank you very much for the lecture, I'd want more and more :-)
I am pleased you enjoyed it. Most people find my diatribes rather dry reading.
> I'm happy to see, almost all of the mentioned (except for bdflush)
> settings are more or less optimum.
Excellent.
I have another idea too. Since in a DAW scenario, it's STUPID to
write-buffer really [you're spooling out lots of data which you're not going
to need again anytime soon], I'd inspect the source to see if they open the
file in O_DIRECT mode. This removes the buffer cache entirely from the
equation and does not induce memory pressures upon the kernel.
All "large spooling" I/Os (read or writes) should use O_DIRECT for realtime
operations where the likelihood of re-reading the file is zero. When you're
EDITING the file, fine. But when you're capturing, I suspect you will see
more wins if you're using O_DIRECT. You can get big wins if you use
O_DIRECT and use multiples of the physical memory pagesize. (Zero-copy write
path - super-dee-duper efficient!)
With O_DIRECT you will eliminate the CPU waste (and locking!!) of wasteful
double-buffering, and reduce memory copying. If you set up the I/Os
properly, you will in fact have a direct-to-disk DMA channel from the audio
buffer. This is Perfection.
> Let me recall my question: I think, there are more than one (lck1)
> possible kernel patches with the aim of solving lowlat/preempt/...
> issues. Which of them is the most appropriate for using with jack?
All of them, though strictly speaking, the 64-bit jiffies patch does not
boost performance.
> I still use 2.4.26.
Sounds fine.
I'm assuming you're using the patches at:
<http://www.plumlocosoft.com/kernel/> (Con Kolivas's patches now maintained
by E Hustvedt).
Apply all of the patches, and enable lowlatency. I use all of them except
for 012-rl2dt.diff.bz2 on my main servers [non-audio/realtime oriented] to
excellent effect.
If you're really hardcore, you can live without 64-bit jiffies, however when
HZ=1000 you'll wrap your jiffy counter in under 40 days.
I think HZ=1000 will get you some gains in responsiveness for applications
which do ANY select() multiplexing. Ignore the rants about "wastes due to
more interrupts" - that's under 1% on modern CPUs. The AXP (Alpha) platform
has been using HZ=1000 for years, and even a $50 Athlon XP 2000 leaves that
for dead. On pre-Pentia CPUs, there's a reasonable argument to be made for
HZ=100.
Lord Sauron could have won, if only he had Quality,
=MB=
-- A focus on Quality.
This archive was generated by hypermail 2b28 : Sat May 01 2004 - 04:22:14 EEST