[linux-audio-user] rezound as jack client

[Malcolm Baldridge]

> 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.