Hi I wanna test the latency on my laptop. To simply test the latency on my system, can I do that: I use ecasound:
- record a foo.wav - play this foo.wav and record a foo2.wav at the same time (input /dev/dsp) - compare with Snd the 2 waves. 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 Andre Pang <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> - trust.in.love.to.save
