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

Jay Ts wrote:

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.

Surely, too, there's a point of dimished returns where no matter what
you do, you still need a certain number of samples buffered. Otherwise,
the buffer adjustment for the driver or DAW program would go down to zero.
I've never seen one that does, and if it did, I wouldn't expect a system to
work that way unless there was a fixed buffer which you could extend with
that adjustment. But wouldn't it make someone feel good to say "I can run
my ProFireBlast with the buffer size set to zero so it must be no latency." <g>

If you don't change the buffer setting, IT WILL STILL BE 10 MS!

That's what I suspected - the buffer size is the big elephant in the room. I'm
sure that the actual latency is the buffer size expressed in time at the given
sample rate plus whatever other delays there are besides buffering. But
you're suggesting that these "other" delays are insignificant in terms of
input-to-output time.

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

I don't think you could ever realize that except with dedicated
hardware and no operating system. In the real world, some delay
as a result of process control is inevitable. No computer can devote
100% of its resources to a single task. Or maybe that's how a multi-core
system works, in effect. But I get the point - the delay could be truly
negligible, not the "negligible" 5 or 10 milliseconds.

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.

While we're doing thought experiments, what part of the delay
budget is due to the hardware (which you can do something about,
at least up to a certain point when you run out of money or technology)
and which part is due to the operating system, which you have to live
with if you want to use a computer to do your recording, mixing, or
signal processing.

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.

It may be splitting hairs, but I suspect that this is not a matter of a
'bad' driver, but rather that when it's enabled, the computer will
continuously search for a WiFi signal, and that's time that it could
be processing audio. I found that on the first laptop that I used for
audio, even for straightforward 2-track recording, I needed an
outrageously large buffer in order not to get clicks and that one didn't
even have wireless Ethernet. It turned out to be the wired LAN
that, even when disconnected, tried to connect to something. In
this case, there was a new LAN driver available from Dell, I installed
it, and that fixed the problem. I didn't have to disable the Ethernet
adapter in order to keep it from clicking.

Just as a matter of course, although I have a LAN connection to my
studio computer, the default hardware profile is with it disabled, and I
can either boot with a different hardware profile or enable it manually
if I want to go on line from that computer or move a file to or from
another computer in the house. Problem is that sometimes it doesn't
work right and even with the "NoLAN" hardware profile selected, it
enables the Ethernet card and connects. But it's Windows (XP).

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.

It would be interesting to see if there really was such a thing as
a better driver. Out of curiosity, I once tried a USB WiFi adapter
on the old laptop without a built-in one (I use an outdated SMC
CardBus adapter with it) and I never got to experimenting with
its effect on audio recording because it wouldn't work where I
wanted to use it (while the other one did).

I haven't bothered experimenting with the laptop that has the
built-in WiFi. Perhaps I should. When I have the WiFi on, say
in a hotel room, I can listen to streaming audio over the Internet
just fine, but then that's using the internal sound card with its
WDM Windows standard driver, and without recording, there's
no concern for latency.

The other problem I had was with the laptop's battery monitor
driver.

Yup, that's another tweak.

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.

Yeah, but you know those $500 perfectionists. <g>

You can check periodically for driver updates, but don't expect too
much, especially if the computer is an old one.

I do, and they're mighty rare after the first year.

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

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.

This is also why some Firewire ports just plain don't work for audio, like,
to the point where the computer won't even recognize that there's
audio hardware connected.

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.

I love this country! When was the last time you saw a transformer isolated
S/PDIF port?

So products
can get to the customer before problems are discerned, and can continue
to be sold for a long time thereafter.

This is particularly true for audio devices. The manufacturers see little reason
to test their hardware with anything other than the sound card that they put in
the computer. After all, they put it in there, dammit, so use it and don't screw
things up.

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.

This is telling you (if it increases) that it's using the disk because it's
run out of usable memory? That could be very bad, not just a "more
latency" issue.

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.

That's just memory necessary to make it work, though. If you're
playing a virtual instrument and don't have enough memory, it'll
probably stutter, not just be sluggish in response to your playing.

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.

When the topic comes up, someone (usually Arny) pipes up with
the calculation of how many bytes per second per track needs to
be moved, and it's well below the specified performance of any
modern disk drive. The Mackie HDR24/96 which can record, play,
and punch-in (potentially three streams) on 24 tracks at 48 kHz,
was originally shipped with a 5400 RPM disk with a 2 MB buffer.
It worked fine. They eventually switched to a 7200 RPM disk because
their suppliers stopped making 5400 RPM drives. Users who
swapped out the internal drive (which also contained the operating
system and application) sometimes noticed that it booted faster
with a 7200 RPM drive, but since it recorded perfectly, it's hard
to notice any improvement in that.

Most laptops still have 5400 RPM drives, so the net wisdom is
to use an external drive for audio, but I don't really know if that
matters. On my old laptop, the USB port is 1.1 and I can record
more tracks on the internal drive than an external one. And
the CardBus hardware is too slow to support a Firewire disk
drive.

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

Oh, it defintiely is. The problem you'll run into, if there's a problem,
will be that you don't have enough CPU horsepower to run all
the plug-ins that you want to use.

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.

Nor should you be expected to. But apparently there are some people
who (maybe for lack of trying) are running with that much latency or more.

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.

How do you measure it? I once tried to kludge up a rig where pressing
a key on the keyboard would fire off an exthernal oscillator, and I could record
that and the output of the sound card playing a virtual instrument. But it
fell apart before I could get any good data.

With a MIDI guitar controller (I have one of those, too) you could use the
pickup as the reference. If it's still raining tomorrow, I'll have to give that
a try if I can figure out how to make a virutal instrument work. I must have
one around here someplace.

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 suspect that's the case - trying to use a DAW to mix, apply effects,
and be the instrument all in one handly laptop case.

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.

I think this is the application which concerns most people. You have
your backing tracks playing, you're doing a headphone mix, and then
you sit down at your black-and-whites to start playing parts on your
virtual instruments.

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

You made me look! That's a tweak toy if I ever saw one.

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

And the answer is "try something else and maybe it'll work better."

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.

I feel that way about even a fixed location DAW, but then I like
working on hardware with components that I can see, connected
with cables that I can plug where I want them (including into a set
of headphones to see if anything's coming out).

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.)

So this is really not a matter of reliability, but predictability - under
what circumstances will it work OK and what makes it start to fail. I
used to point this out to people in the early days of DAWs - that they
might have 20 tracks working just fine, and not be able to record the
21st track without things going to pot. Or today they put a compressor
on a track that they didn't have yesterday and now yesterday's 20
tracks won't play right.

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."

Certainly a good thing. But these people also don't want to have to
use another computer for net surfing, or doing their client billing. And
they want to have their e-mail program open while they're working in
the studio so they won't miss out on an eBay bid or dinner plans.

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.

Yes, I indeed started with "standard recommendations" and didn't get
very far away from those. But there are long lists and short lists. And
for every long list, there's someone with a short list who will tell you
that anything other than what's on his short list, while valid in principle,
won't make a significant difference. And other will say that ANY difference
is significant. So while there's guidance, there's a certain amount you
need to take on faith or a hunch.


.

Relevant Pages