So, is there a way of objectively measuring latency and determining what Asio latency to use?
At the moment, I do it all by ear, and that’s something that I have to adjust depending on the VSTi.
But, there has to be a way of doing it objectively, isn’t there?
And this refers to the video card latency adjusters mentioned in another thread too. I would like to determine accurately, what effect adjusting other non sound card latencies has on my audio performance.
And keep the answers simple, computers are not my area of expertise. 
Ali
Anyway Jeff, here’s what PCI Latency tool is telling me:
PCI bridge: 64
Multimedia audio controller: 32
Midi/gameport: 32 (I use that for my MIDI keyboard/controller)
Firewire (which I don’t use): 32
Ethernet (which I don’t use): 32
ATI Radeon card: It was 256, but following your suggestion, I’ve changed it to 96.
All other devices listed have latencies of 0.
Ali
Im not sure about the thread you mention, but be aware that any tweaking you make to the Graphic Card can affect your soundcard and other pci peripherals if they share the same type of bus. An example is that reducing the “Graphics acceleration” many times helps to reduces problems with soundcards performance. Is not a main rule, but is true in my case.
BTW, why are you using this PCI Latency tool instead of the ASIO control Panel or WDM setting window?
Marce:
“On location last weekend…”
Starting last post on page 3.
And continuing sporadically till the end of page 7 (whereupon Jeff gave me a telling off! )
Ali
ok, continue tweaking… 
Hi Heres a link to an interesting article on really measuring latency by recording the MIDI control signal and comparing it with the generated sound.
http://www.soundonsound.com/sos/Sep02/articles/pcmusician0902.asp
Nick
I set my Matrox=16 and everything else=8 and the system runs superb. ASIO at 48 samples no problem. However, CPU increases dramatically when ASIO is this low (and this is not because PCI latency is set so low).
Basically the PCI latency timer determines how long a device on the bus will hog it before it lets another device take a turn hogging it. For audio, it’s best to use very small time slices. Your video card won’t have stellar benchmark test scores anymore, but your audio is likely to perform much better. If you aren’t playing 3D games, it should work great. If you are doing gaming, get a latency config software that lets you store profiles.
As for ASIO buffer sizes, general rule of thumb: run ASIO small as possible when doing VSTi work (and use as few tracks and FX’s possible). Run ASIO large as possible (or even better, use MME) for doing mix work.
Of course YMMV, JMO, etc…
So Sekim, do you recommend I turn the graphics card latency down as far as it will go?
I don’t use the PC for games, (well, apart from Hearts and Solitaire once in a while ), so I want it to be as good for audio as it can be, and to h e ll with everything else.
Ali
Every system is a bit different, but I’d try video=32, everything else=16 and see if that works out. If so, try video=16 everything else=8.
OK, did that, and nothing has crashed so far!
I’ll log off and try playing my soft synths and generally bugger around with stuff and see how it goes for a day or so.
Thanks Sekim.
Ali
PS, thanks Nick, interesting link, I’m studying it now.
Try your video card at 64 and don’t worry about the rest.
Only the biggest number in the list matters. Currently that’s 96. If you set it to 64, then there’ll be two at that value, and you’d have to reduce both to get an improvement. I don’t know the facts about how to calculate audio latency in milliseconds from PCI latency in cycles (or whatever these units are), but I’ve heard folks report excellent results using 64.
To measure millisecond-level times in n-Track’s timeline, right click on one of the timeline bars (where the times are displayed) and set the time format to “Custom” and enter 1000 in the box (I think it’s called “frames per second”). This will cause N to display the time in this format:
mm:ss.xxx
where “xx” is the time in milliseconds. But note carefully: when the milliseconds is less than 100, it only displays two digits. So just remember that 1:01.22 comes before 1:01.202 (180 milliseconds before). So it’s not like reading decimal fractions. (That trips me up now and then.)
To measure total latency for MIDI & softsynth, put a mike by your keyboard – miking the key you’re going to whack. Set up in LIVE mode, playing the softsynth through the monitors. Use a percussive sound in the softsynth – anything with a good sharp attack. Put the monitors close to the mike, or else remember about 1 msec per foot (closer to 0.883 msec, really – but I use a msec as a rule of thumb). Set the volume high enough to hear clearly but low enough to hear the key being whacked.
Start recording, and whack a key.
Inspect the resulting wave file. You should be able to see the sound made by whacking the key and the sound made by the softsynth, which follows. Measure the time difference, as above.
This has some advantages to the method described in the link:
- it doesn’t require any hardware mods
- it includes the latency in your MIDI keyboard.
- it includes MIDI shift-in latency (about 1 msec)
You’re measuring the REAL, total latency you experience as a musician playing the soft synth. No fudge-factors required. Using this as well as the method posted above and adjusting by 1 msec, you can measure your MIDI controller’s latency, and deduce the latency in the computer.
Oops, I misread your post – you said nothing crashed. I though you said it HAD crashed, so just ignore what I said about using 64.
I made another mistake above, possibly, and it depends on interrupt priority. What I said above is true only if your soundcard’s PCI bus priority is the same or higher than any of the others.
That sounds a simpler way of doing it Jeff, I’ll give it a try.
But, I’ve been running at Sekim’s suggested settings for a day now, and all seems ok (so far).
I’ve been playing with my new toy, Linplug’s Saxlab VSTi, and I’m managing to get my Asio soundcard down to 5mS now with no pops or clicks.
But I assume you read Nick’s link?
One point in there I found interesting was something we were discussing several weeks back, which was, which is better for a MIDI keyboard/controller, USB or the standard MIDI UART.
And it seems from the article, that the UART gives less jitter, which matches my own (very subjective) experiences. And I seem to recall that you too were a bit doubtful about the timing accuracy of USB.
Ali
Glad to hear setting your PCI latency helped matters. It likely helps midi as well for similar reasons and regardless of hardware. Some hardware will perform beter than other, but any midi hardware should see improvement. You can check midi latency and jitter with this:
Midi Test Utility
Err, just to clarify, ASIO latency has no direct measurable relationship with PCI latency. Yeah, you can tweak the PCI latency to potentially get a lower ASIO latency, but there is no equation to relate one to the other. The biggest factor in ASIO latency is how well the drivers are written. PAst that it is all about disk IO and memory. Unless you have major issues with latency, I wouldn’t mess with the PCi timing as a habit. It is just a waste of time for very little advantage IMO.
Er, just to clarify, ASIO latency is directly affected by overall PCI performance. It’s easy enough to test, go set your video card to PCI latency = 256 and try running ASIO at 48 samples and let us know how it went for you…
I’m going to try your settings, sekim. I’d like to get a better handle on this whole thing.
In general, for audio, I’ve always thought the PCI latency adjustments were mainly targeted at drop-outs (snap, crackle, pop) rather than plugin stimulus/response latency. Not that it always works, though; there are times where I could have sworn that reducing my video card’s PCI latency fixed dropout issues, but I just can’t seem to collect consistent, hard evidence of this (on my own box, that is). Also, you’d think that reducing the PCI latency settings by a factor of four (i.e., 32 down to 8) would yield a four-fold increase in the number of CPU interrupts for the same bus traffic, thereby increasing CPU load, but I haven’t seen any noticeable impact in practice. I’m starting to wonder if PCI latency settings make more of a difference with slower processors than faster ones or something…I dunno. 
But in the end, hey, whatever makes things work is great!
On the other hand, I definitely see the buffer settings’ effectiveness in fixing both drop-outs and plugin latency issues based on just my own somewhat limited experience! I’ve also seen it affect CPU usage.
One thing that would be cool is to have some buffer meters that show the status of the various buffers–kinda like what CD burning software uses for the disk buffer during burning. Sometimes I record a track that has one or two d*mn little dropouts in the recorded audio, and after making adjustments, I hate having to listen to a whole re-recorded track just to see if that one pop is really gone. I’d like to have something that visually alerts me to drop-outs, kinda like the clipping indicators on the VUs.
Tony
Maybe a feature request for new versions of n-Track? Drop-out detection would be good although, I don’t have the problem at the moment. I know Sonar has this as does Magix Audio Studio and Samplitude. Not exactly sure how it works…
TG
PS My ATI Radeon runs at 255 and I run ASIO down to 5ms at 24/48 with no problems.
Here’s a good read on the subject.
The “Bus Arbitration” section indicates why low ASIO buffer sizes would benefit from low PCI latencies on other devices.