Re: Real World Significant Sources of (what we usually call) Latency

Mike Rivers wrote:
Jay Ts wrote:

This is the sort of thing that I want to know about. Will getting a
faster CPU, more RAM, and tweaking actually help to reduce latency?

Generally, the answer is "yes". But since computers are complicated,
don't take that too seriously. ;-)

Surely it can't hurt, but how much will it help? And in what way?

I think what you're looking for here is an answer like, "If the
CPU is twice as fast, you can reduce your buffer size to half."

And that might be approximately true. But it gets complicated really
fast. There is no way to rate one CPU compared to another using a
single number, because differences in architecture cause the CPUs
to perform at different relative speeds for different types of tasks.
And that's just for starters.

For example, let's say you've managed to get the input/output latency
down to
10 ms with your present system. If you get a faster CPU (how much
faster?) and
adding more RAM (how much?), without changing audio buffer setting, get
the latency
down to, say 5 ms? Or only 9.5 ms?

If you don't change the buffer setting, IT WILL STILL BE 10 MS!
The buffer setting is the number of samples, and they are taken
at the sample rate (e.g., 44.1, 48, 96 or 192 KHz). It is not
keyed to CPU speed.

But if you have a faster CPU, you can reduce the size of your buffer,
and from that, you can get less latency.

About this issue, try this thought experiment: Suppose you
have an almost infinitely fast CPU and memory system, with
nothing that can distract it from processing audio. In that
case, you wouldn't need a buffer at all. The audio device
would pass a sample to the CPU, and it would pass that to
the application, and the application would do its thing, and
pass the output back to the audio device by the time the next
sample was ready at the input. Total latency would be one
sample (something like 20 microseconds for a 48 KHz sample rate --
and I'm doing this off-the-cuff, so I hope I got that right!).

But in real systems, many things can happen to distract the
CPU. So you need a buffer with enough samples to allow the
CPU to do that other stuff, and then get back to processing audio.

If the CPU is slow, then it will take longer for it to return
to processing audio, so you need a larger buffer to give it the
required time. With a faster CPU, it takes less time, and that's
how you get less latency.

A secondary effect, and this is significant, too, is this. With the
hot-rod computer,
will it be possible to reduce the buffer size to gain the associated
reduction in latency?

Yes, that's it. Except that I would call it a primary effect, not
secondary.

Again, how much?

Again(!), it's really impossible to predict this. But, if you have
CPU/memory that's twice as fast, I think you can expect to achieve
around half the latency. But I'm not really, really sure about that.
I would expect as CPU speed increases, the latency may be dominated
by other factors, and since like you, I'm also way behind in technology,
I don't have much feeling for it. At the limit, you can't have
less than 1 sample of latency, so use the 1/x key on your calculator
to determine the theoretical minimum for various sample rates.

In other words, is it hopeless to try to significantly improve latency
by "improving" the computer?

It's been my experience so far that every time I upgrade CPU performance,
I can use a smaller buffer and get lower latency. But as I just wrote,
there may be (and I assume there is) a limit to what can be gained.

Another is a badly-written device driver that takes up the attention of
the CPU and can't be interrupted. The DPC Latency Checker is a very
good tool for finding those on Windows.

That's another good thing to check. Sometimes you can do something about
this by disabling the device that uses that "bad" driver if you don't
need it. But suppose it's something that you can't get along without?

Well, on my laptop, the worst offender was the WiFi driver. I don't
need that while doing audio processing, so I disabled it.

If I needed to use WiFi concurrently, I would have to keep the
onboard device disabled. Enabling it is absolutely not an option,
because it was causing 22 ms of latency, at regular intervals!
There was a click each and every time, no exceptions, even
when running the simplest and most efficient software, within
acceptable buffer sizes and resulting latency.

So instead, another option would be to try a CardBus or USB
WiFi adapter, and look for one with a better device driver.
And yes, that involves spending a little extra money.

The other problem I had was with the laptop's battery monitor
driver. Along with WiFi, this is another common problem (according
to previous posts here). It was no problem to disable that, since
I run the laptop off of the power adapter.

Aside from my own experience, if you can't get along without
an offending driver, and you can't replace it (either with
a driver update or alternate hardware), then you're stuck.

And in that case, maybe it's time to consider that a few pops
and clicks in your audio once in a while aren't so bad after all. :-P
What else can I say here? It's the bottom line, I think.

Unless the computer manufacturer (or hardware manufacturer) has an
alternate driver to offer - I'm thinking Windows here were most all the
utility devices
like printers, disk drives, keyboards, and system devices, are built
into Windows - there really isn't anything you can do about this.

You can check periodically for driver updates, but don't expect too
much, especially if the computer is an old one. I found driver updates
for my WiFi driver and audio device driver, along with others, and they
didn't help AT ALL.

To keep things in perspective, computers are sold in a competitive
market, and the primary users are now interested in the Internet,
and maybe not much else. They want laptops, partly because they
can be moved around and run off the battery. So the manufacturers
want the WiFi and battery monitoring to work well for them.

We (musicians and pro audio folk) aren't getting priority
consideration from the designers of the products, and I don't
expect things to change much very soon.

> On Linux, I *think*
this is much less of a problem, because device driver writers are
instructed to absolutely avoid writing drivers that way

Seems like that would be a good thing for people writing Windows
drivers, too.

Of course. And maybe they are told basically the same thing ...
but there is a difference between the Open Source world and the
closed, proprietary world. If the developer of a Linux audio device
driver does something bad, the code can be looked at by others,
and he can expect flames. Along with that, the kernel developers
may refuse to include the driver until it is fixed.

This kind of peer review may not happen for a Windows driver.
Microsoft sets some standards, but AFAIK, there is no requirement
that developers follow them if they don't want to. So products
can get to the customer before problems are discerned, and can continue
to be sold for a long time thereafter. At least, that is a possible
explanation. I honestly don't know enough about these issues to
say anything really definitive. I hope I don't start another
Linux Advocacy diversion(!), and I'd like to know more about how
this issue is handled in the OS X world. I suspect it is much
better than for Windows.

Beyond a certain point, adding more
memory will have little additional benefit. And overall, unless your
system has too little memory to basically function, it won't have a
significant effect on latency issues.

OK, that's one good data point, given that you know how much RAM is
enough.

The amount you need depends
on specifically what you are doing (DAW, virtual instrument, digital
effects box, etc., and your specific project's needs). Computers seem
to come with gigs of memory nowadays, so I wouldn't worry much about
it.

So is the process to add more RAM and see if anything improves? Or take
out some RAM and see if it gets worse?

You can do that. ;-) But you can also open the Windows Task Manager
(right-click on the taskbar and select Task Manager), and
and in the Performance tab, watch PF Usage and PF Usage History.
The PF Usage bar graph should stay at it's lowest position (one line),
and the PF Usage History rolling chart should show a flat, horizontal
line. It is normal to see a *little activity* there, but if more,
it is a good indicator that you need to add memory.

There is no rule for how much memory to add for audio applications,
because you may need almost none, or you may be able to use
as much as you can afford, or your computer can take.

If you just want to run a simple VST host to use the computer
to function as a digital reverb, it takes very little memory
to do that. You will not need to add memory.

But if you are running a virtual sampler, and you have high
expectations of what you can do with it, you can use gobs
of memory. Samplers allow you to set the amount of memory
that the first part of each sample is pre-loaded into (E-mu
calls it "pre-roll", and Kontakt has a different term for it).
If you set that sufficiently large, you may be able to load
the entire instrument into memory. Cool, eh? Well, for one of
the larger sampled pianos, this can easily be over a gigabyte.
I think there are a few multi-gigabyte pianos available now.
From there, you can add more instruments, so you can switch
presets in the sampler. I'm not sure if there is a limit to
how many banks and instruments in any current software sampler.

The actual limitation on this may be the amount of time it
takes to initialize the application, because all of those
gigabytes have to be transferred from disk to memory. (This
is actually a problem I am dealing with already, without
multi-gig pianos, or loading all of each sample.)

But, if you can pre-load samples, it cuts down on disk
accesses, and there may be a positive effect on system
efficiency that allows for lower latency. So there is
an extreme example, that is not even very far-fetched,
of how adding memory *may* help.

Disk I/O is buffered both
ways, and if your audio app is clicking due to disk accesses, there is
something basically wrong with its design. Or you are simply at the
limits of what your current hardware is capable of.

Disk drives have had pretty good sized buffers for many years now, so
this is not likely to be a problem.

What I meant was this: there is a point where the maximum transfer rate
from the disk subsystem is simply overwhelmed. In that case, no
amount of buffers in the disk will help you. You are at the limits
of the basic hardware. Unlike the example I described just above,
there are also plenty of cases where adding extra system memory
won't help either.

Since CPU speeds have been increasing faster than disk speeds for
a long time, I assume that disk speed is the limiting factor for
multitrack recording. But I am not doing any of that, so maybe
someone else can confirm or refute this.

If it's possible to do 32-track mixdowns on a single, SATA
drive, then ignore everything I wrote on this topic. ;)

First of all, if you are using a sampler that doesn't do disk
streaming, then you need to modernize. All of the major samplers can do
that now

So why do people complain about latency with virtual instruments?

Wow, do they? Still? I know it used to be a very common complaint.
But that was when 25 ms. of latency from the device driver was common.
In the early days, I couldn't use softsynths because of that.

Even on my slow, old systems, I get 5 ms. or better, and that's
plenty good for me, even with the additional latency caused by
MIDI input, softsynth app, VST host, and my guitar-to-MIDI
converter, which by itself is responsible for several milliseconds.

If musicians are complaining about latency in virtual instruments,
maybe they are doing something wrong(?), or maybe they are using
them inside of multitrack recording DAWs, or some other configuration
I haven't tried yet. I would guess that the latency problem is
not from the virtual instrument, but other things.

For example, I've tried a few VST host applications, and some
of the cheaper (free) ones use up a lot of CPU power - 2-3x
as much as others. This alone may force the use of a larger
buffer, and result in more latency. I found the free VST hosts
unusable because of that. I haven't even tried
a huge thing like Cakewalk or Cubase as a VST host yet. If
the virtual instrument is being used at the same time many
tracks are playing back, with other plugins running, adding
a virtual instrument could easily consume enough additional CPU
to create a problem, where there previously was none.

While on this topic, another recommendation for monitoring
system resources is gkrellm:

http://members.dslextreme.com/users/billw/gkrellm/gkrellm.html

It can be a complicated little devil at first, so expect to
spend some time configuring it. But I've found it very useful
for monitoring CPU usage and memory usage. One caveat: gkellm
itself uses significant CPU, and can force you to use larger
buffers! So use it for diagnosis, and turn it off while you're
actually working. (I am running an older version, 2.3.0, which
uses less CPU.)

Does it have to do with the VST system, as most use?

I would not blame it on VST itself, but rather, how the
VST host applications are implemented. Some are better than others.
I don't know if any directly introduce significant latency; as I wrote
above, the main problem was from the extra CPU power a poorly-written
one consumes.

So some virtual instruments are better than others.

Well, of course. :)

I thought more about what I wrote last
time, and I think that most virtual instruments work more-or-less
like good "realtime" (low-latency) VST effects plugins.
That is, they process one sample at a time, and add it into
the output buffer. When that is full, the buffer sent to the
audio device driver. So you'll get some additional latency from the buffer
in the application, which hopefully is very small. At least, that's
the way it worked for me years ago when I wrote a very simple
software sampler for Linux. That was on just a 200 MHz Pentium, so I got
a good lesson in what can go wrong! But someone who is currently (or has
lately) written apps for Windows knows this stuff better than I do.

The bottom line, though, is that you are at the mercy of the
application developer.

But it seems
that a lot of people (and again, I think this is a money-and-gear issue)
are wanting to play virtual instruments live.

Well, that includes me.

That's probably going to
mean "get a better instrument." Or will "get a faster computer" help in
this instance?

The biggest problem I'm having is not latency. I'm using a
2 GHz Celeron with 1 GB of RAM and a 5400 rpm hard drive.
(I upgraded the memory to 1 GB, and from a 4500 rpm drive to this one,
and both helped, especially for running software samplers.)
After disabling the WiFi and battery monitoring drivers, my
latency is low enough that I naturally adjust for it, and it
is simply never a problem as far as I can tell.

My biggest problem, and this is still somewhat of a showstopper,
is reliability. The whole system is complicated, and there are too
many weak points. You are "not supposed to understand this", but
my main strategy at this point is to buy a new laptop, because I
believe that more CPU power and memory may solve some of the problems!
(To explain a little: I strongly suspect that some of the problems I
have been experiencing are due to pushing the system a little high
in CPU and memory usage. But I can't really prove it.)

I think the main thing that is important isn't so much to get a really
fast system, but to avoid including things that would slow it down or
interfere event handling. Such as Vista, bad device drivers, too many
background tasks started at boot time, other "enhancements" added by
OEMs, or malware.

In other words, "optimize."

You could call it that, yes. But the way I think of it is to
re-configure the computer for use with realtime audio, instead
of its typical configuration that is intended for Internet users,
office workers, and other "typical customers". So, I would say it
with more words: "optimize for realtime audio."

My own experience with optimizing computers
for audio using the well known tweaks has shown me much of an
improvement, but I think that's just because I don't run anything very
close to the edge. When
I try to reduce the buffer size to the point where it becomes flaky, I
find that
it becomes flaky at that buffer size even with what I've tunred off
turned back
on.

I don't know, really, but maybe many of the changes you made were
from "standard recommendations". Many of the ones I've read about
and used here do not make any noticeable difference over any short
time period, but they are still good advice. One example is to
set the virtual memory size to a constant, disallowing Windows
from resizing it. That is something that would happen rarely, if ever,
but if it ever does happen, it's almost guaranteed (I think) to cause
a huge glitch. Or at least, it is very likely. You could argue that
since you made sure to have plenty of extra memory, then Windows
would never have to resize the virtual memory space, but the problem
is that you have no guarantee from Microsoft that it won't do it
anyway, as a result from some strategic algorithm in use. With a lot
of these things, it's like that. Better safe than sorry.

Jay Ts
--
To contact me, use this web page:
http://www.jayts.com/contact.php
.

Relevant Pages