Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
Hi
- record a foo.wav
Is the result reliable? Does the difference between the times when the waves start give me the latency of my machine?
On Wed, 3 Oct 2001 22:50:45 +1000
> On Wed, Oct 03, 2001 at 08:09:53AM -0400, Paul Davis wrote:
This archive was generated by hypermail 2b28
: Mon Oct 08 2001 - 12:29:31 EEST
From: CLOTILDE (guy.clotilde_AT_wanadoo.fr)
Date: Mon Oct 08 2001 - 12:28:35 EEST
I wanna test the latency on my laptop.
To simply test the latency on my system, can I do that:
I use ecasound:
- play this foo.wav and record a foo2.wav at the same time (input /dev/dsp)
- compare with Snd the 2 waves.
Andre Pang <ozone_AT_algorithm.com.au> 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