Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...<g>

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
From: Andre Pang (ozone_AT_algorithm.com.au)
Date: Wed Oct 03 2001 - 15:50:45 EEST


On Wed, Oct 03, 2001 at 08:09:53AM -0400, Paul Davis wrote:

> >On Karl's paper of latency measurements there was mentioned that the low-
> >latency patches have actually little effect and the reasone for bad latency on
> >some systems is actually IDE. Could you actually tell as more about this,
>
> this is not strictly true. the IDE drivers (and devices) are the worst
> offenders, but they are far the only place in the mainstream kernel
> where the kernel could block a runnable task for a (very) long time.

This is true, but turning on DMA support for the IDE hard disk
lowers your latencies and CPU usage by several orders of
magnitude. Try running the "hdparm -d1 -X66 /dev/hda" command.
Replace /dev/hda with your hard drive, as appropriate. -X66
is DMA mode2; the newest HDs and chipset may be DMA mode3, 4, or,
5, which are -X67, -X68, and -X69, respectively. Try them in
reverse order; you'll just get back a "DMA mode not supported"
message if your HD/chipset can't handle that speed.

If anybody's really interested, I can do benchmarks to see what
the difference is ...

> for example, even in 2.4.0, with the low latency patch, it was
> possible to cause scheduling delays of 30-50-1000! msecs by hitting
> the VM and disk subsystems (e.g. a 4-process C++ compile while running
> Ardour).

I wonder if Robert Love's kernel pre-emption patches would make
this better. Has anybody tried them extensively? From what I've
heard on the kernel mailing list, people are _very_ happy with
them. (Happy == xmms skips once in a blue moon with uptime loads
of >10, including hitting the VM and disk hard.) I'm using it
here, but I'm not doing anything extensive. (Yet :).

> >should I get SCSI interface and systems for low-latency work? Also could you
> >explain why Windows system with IDE (with busmastering drivers/interface) and
> >ASIO drivers work well enough?
>
> The Linux ones will work well enough when tuned correctly, and
> combined with a low latency patch. Presumably, the Windows ones are
> already tuned properly, and Windows had a better design for mid-range
> latency than Linux (they both failed in the low-latency case,
> however; this is where the low latency patch came in).

Addendum to Paul's reply: I think ASIO on Windows is able to get
such low latencies because it requires specific ASIO drivers for
sound cards, and these drivers bypass the normal kernel mixers
etc. I think GigaSampler's GSIF does something similar. It has
its own problems; if your audio application crashes in Windows,
your sound card's resources won't be properly released, and you'll
have to reboot to get it working again at all. Boo, hiss. And of
course, vendors have to write ASIO drivers for their soundcard in
addition to the standard Windows drivers, which sucks nads.

-- 
#ozone/algorithm <ozone_AT_algorithm.com.au>          - trust.in.love.to.save


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Oct 03 2001 - 15:48:54 EEST