Real World Significant Sources of (what we usually call) Latency
Mike Rivers
gather some usable data on just what affects latency in a digital audio
path significantly, and what affects it theoretically (everything does, I
know) but by an insignificant amount relative to the total delay time.
Why am I asking? Well, I've been dispensing advice about this, it seems,
more and more these days (must be the holiday shopping-lust season)
and I realize that I'm not very up to date because I don't use virtual
instruments, I don't monitor through a DAW unless it's someon else's and
I can't possible help it, and my computers are a few generations old. I'm
wondering if I'm missing something important in the way these systems
are used today, if I'm telling people to worry about things that they
needn't
worry about, or if I'm missing some things that they should worry about, in
terms of being able to make improvements by tweaking, software, or
hardware selection.
Let's start by talking about monitoring latency - microphone in to headphone
out.
For example, A/D and D/A converters generally have somewhere between
1 and 1.5 ms delay at 44.1 kHz - hook a pair back to back and the analog
output
will be roughly 2 ms behind the analog input.
Put a computer in the middle and that includes the time for the computer
interface
(direct CPU bus, USB, or Firewire) to do its thing, each with a
different amount of
throughput delay, for the drivers to pass the data two and from the CPU,
and the
processing time it takes for the CPU and software to turn the audio
around and
spit it back out. I know, for instance, that properly designed ASIO
drivers can in
essence (if not exactly) bypass some of the path and, for monitoring,
turn the input
around and send it to the output without significant CPU involvement,
and this
is indeed a significant improvement over plain vanilla (WDM) drivers.
How about the differences between how Windows and MacOS handles talking to
an external interface? In Windows, most all USB audio devices use a
class-compliant
Windows driver (am I saying that correctly?) but when it comes to
Firewire, it's every
hardware developer to himself, usually with some help from their chosen
chipset
developer. On a Mac, most of it uses the Apple Core Audio system which
usually means
that there's no driver to load (though often a control panel).
What about what goes on inside the computer? Given that the DAW program
and operating system can take advantage of it, does a quad-core CPU turn
around
the data significantly faster than a single core one? Or does having
gobs of RAM
make a difference?
Since most all driver "control panels" allow you to set buffer size,
this is going to
have a large, probably the largest, effect on latency. The advice to
reduce the
buffer size until recording becomes unreliable, and then jack it back up
is well
known. Almost as well known is that different systems will choke at
different
buffer sizes, and that this can usually be optimized by making the
computer less
busy.
And how about hard drive throughput? Is the difference between 5400,
7200, and
10,000 RPM significant with modern drives? How about the difference between
EIDE/ATA-133 and SATA?
Now, about another kind of latency that's a matter of concern for many -
playing virtual
instruments inside a DAW, generally VST plug-ins. Where are the
significant bottlenecks
between the time you press a key and when you hear a sound? Does
everything these
days get played out of RAM, so disk access and throughput speed doesn't
affect this delay?
I'm trying to get past the obvious "get the fastest system you can and
optimize it" and
get a more up-to-date view of where the real problems lie, what matters
most, and what
matters least.
Laurence Payne
wrote:
>I'm trying to get past the obvious "get the fastest system you can and
>optimize it" and
>get a more up-to-date view of where the real problems lie, what matters
>most, and what
>matters least.
I think all that really matters is deciding whether you're sensitive
to a couple of ms delay in your monitoring. If you are, it matters
little whether you can tweak this figure. Just duck out of the
problem and arrange monitoring through an external analogue mixer.
Sean Conolly
tests on my new system (2.8G Core 2 Duo). Of course I still don't have new
interfaces to use, so you'll have to take it for what it's worth. Sorry
Mike, I know this is a little tangental to your question, but it piqued my
interest so I had to try it out.
------------------------
Equipment: Octava MC-012, RNP, EMU 0202 USB, MOTU 1296. All tests were done
by recording one channel direct, and the loopback output into the other
channel, and then checking the difference in the recorded waveform.
Control test was measuring recording both the balanced out and insert out of
the RNP on two channels. Not surprisingly, no measurable latency :-)
Next test was RNP into EMU on one channel, and EMU output into the other,
using the 'direct monitoring' feature. Tried both combinations of left vs.
right with same results - consistantly 5 ms delay between the two channels.
This leads me to believe that the direct monitoring is in the digital
domain.
Then the RNP into the MOTU, using the MOTU CueMix app to provide monitoring.
Delay was consistantly 14 ms - thats a lot! Wait, that's with the buffer
size set to 1024 samples. Tried again with 32 sample buffers, the smallest
selection in the GUI, and the delay was 4 ms.
Now granted, I should have dragged out the O-scope and measured the delay
from RNP out to the loopback output, but I figure the input latency is the
same for both channels, so that factor should be cancelled out for all
practical purposes. Especially when we're dealing with millisecond
latencies.
Final test was to record one wave first, and then playback and record it
onto a second channel. The purpose of this was to introduce the CPU and ASIO
driver into the equation. The delay between the two was zero - which just
shows that the software was compensating for the delay by shifting the
recorded track. No idea what the real latency was.
------------------------
Anyway - the conclusion for me is that a new PC doesn't make my old
interfaces any faster (duh!). In both cases I was using features of the
interface which bypassed the driver & CPU. VSTi instruments are going to be
rendered by the CPU and will be played back through the driver, and then
enter the hardware path that I was measuring above.
This sort of implies that there could be a real difference in the latency
depending on the quality of the plugin. For any algorithm, you can only
tweak it so much for speed, but there are an infinite number of ways to make
it run slower.
The other big issue is whether the DAW software uses multi-threading to take
advantage of the multiple cores. None of the old/cheap/free stuff I use
does, but if I eventually get around to upgrading that will be high on my
list to look for: at least the ability to run VST plugins across all the
cores.
Sean
Mike Rivers
> I think all that really matters is deciding whether you're sensitive
> to a couple of ms delay in your monitoring. If you are, it matters
> little whether you can tweak this figure. Just duck out of the
> problem and arrange monitoring through an external analogue mixer.
Hey! Don't duck out of the problem! I'm trying to learn something about
computers here. You can say "Well, don't do that!" to solve nearly any
problem.
Mike Rivers
> Control test was measuring recording both the balanced out and insert out of
> the RNP on two channels. Not surprisingly, no measurable latency :-)
> Next test was RNP into EMU on one channel, and EMU output into the other,
> using the 'direct monitoring' feature. Tried both combinations of left vs.
> right with same results - consistantly 5 ms delay between the two channels.
> This leads me to believe that the direct monitoring is in the digital
> domain.
This is what I call "Zero latency monitoring, for large values of zero."
Surprisingly,
a lot of manufacturers call this "no latency monitoring" when it really
isn't. But at least
it's lowerer than going through the computer.
> Then the RNP into the MOTU, using the MOTU CueMix app to provide monitoring.
> Delay was consistantly 14 ms - thats a lot! Wait, that's with the buffer
> size set to 1024 samples. Tried again with 32 sample buffers, the smallest
> selection in the GUI, and the delay was 4 ms.
This is a software mixer that you operate from the computer? In that
case it would
have to go to and from the computer, though not through a recording
program. Since
that's a round trip through the drivers, it's not unexpected that the
buffer size would
have an effect. What sample rate were you running it at? Those numbers
seem about
consistent with 96 kHz.
> Final test was to record one wave first, and then playback and record it
> onto a second channel. The purpose of this was to introduce the CPU and ASIO
> driver into the equation. The delay between the two was zero - which just
> shows that the software was compensating for the delay by shifting the
> recorded track. No idea what the real latency was.
Yeah, it's amazing how good stuff gets in the way sometimes. Can you
disable the
latency compensation, perhaps by choosing to enter a value manually, and
enter 0?
Of course the latency is still there, it's just that when the file is
saved, the time stamp
(and hence its position) is adjusted by the amount of time that the
driver sends to
the DAW program.
> This sort of implies that there could be a real difference in the latency
> depending on the quality of the plugin. For any algorithm, you can only
> tweak it so much for speed, but there are an infinite number of ways to make
> it run slower.
The only thing that you have real direct control over is the buffer
size, and your
low limit for that is when it won't record or play back reliably. And
that's at least
somewhat a function of the computer hardware, but I'm wondering how much,
or if it's mostly about other stuff that's running at the same time as
the DAW and
taking its attention away from doing what you want it to do.
> The other big issue is whether the DAW software uses multi-threading to take
> advantage of the multiple cores. None of the old/cheap/free stuff I use
> does, but if I eventually get around to upgrading that will be high on my
> list to look for: at least the ability to run VST plugins across all the
> cores.
I don't know anything about mult-threading other than the term. If a
plug-in had
essentially its own CPU to run in, that seems like it would take a load
off the
CPU that's running the DAW program, and allow you to reduce the buffer size,
therefore reducing the latency.
Somebody must have experimented with this.
polymod
"Mike Rivers" <mri...@d-and-d.com> wrote in message
news:hepfov$p47$1...@news.eternal-september.org...
Mike,
Wasn't this the idea behind Yamaha's DSP Factory?
http://www.yamaha.com/yamahavgn/CDA/ContentDetail/ModelSeriesDetail.html?CNTID=2086&CTID=228600
I found this thread fascinating. Being a progressive rock/jazz keyboardist,
I'm always fighting the latency issue and usually relying on my archaic
dinosaur analogue synths......not that I'm complaining<g>
Poly
polymod
"polymod" <pol...@optonline.net> wrote in message
news:4b1045d7$0$22546$607e...@cv.net...
> Mike,
> Wasn't this the idea behind Yamaha's DSP Factory?
Oops.
You did say "plug-in"
My bad.
Poly
Mike Rivers
> Wasn't this the idea behind Yamaha's DSP Factory?
Geez, I remember that one, but I never knew anyone who used one. I
wonder whether it
actually came out, or how well it worked. These days we have a lot of
hardware that
combine a Firewire or USB audio interface with some built-in DSP for
mixing, but generally
that mixer is confined to monitor mixing to minimize (and stabilize)
monitoring during overdubbing.
If you don't have a problem with a couple of milliseconds of latency in
your headphones, you
can make the buffer size (for recording) as large as you need for
reliability without having
to depend on the DAW's mixer for monitoring. But if you want to monitor
with your plug-in
effects or play a virtual instrument live (even live when tracking) you
still need to listen to
what's coming out of the DAW.
> I found this thread fascinating. Being a progressive rock/jazz
keyboardist,
> I'm always fighting the latency issue and usually relying on my archaic
> dinosaur analogue synths......not that I'm complaining<g>
Of course if you have a real mixer you can monitor your synths in real
time without
going through the computer.
Sean Conolly
news:hepfov$p47$1...@news.eternal-september.org...
I'm pretty sure that it's a just a controller for what the MOTU hardware
does - you can close the application but the hardware stays in that
monitoring configuration. For both the EMU and the MOTU the direct
monitoring works even if there is no app running on the system to use it.
This was at 96K, as you guessed.
>> Final test was to record one wave first, and then playback and record it
>> onto a second channel. The purpose of this was to introduce the CPU and
>> ASIO driver into the equation. The delay between the two was zero - which
>> just shows that the software was compensating for the delay by shifting
>> the recorded track. No idea what the real latency was.
>
> Yeah, it's amazing how good stuff gets in the way sometimes. Can you
> disable the
> latency compensation, perhaps by choosing to enter a value manually, and
> enter 0?
> Of course the latency is still there, it's just that when the file is
> saved, the time stamp
> (and hence its position) is adjusted by the amount of time that the driver
> sends to
> the DAW program.
It's not a value I can set - I think it just records that the input stream
started at the moment I punched in, regardless of when the data started
arriving.
>> This sort of implies that there could be a real difference in the latency
>> depending on the quality of the plugin. For any algorithm, you can only
>> tweak it so much for speed, but there are an infinite number of ways to
>> make it run slower.
>
> The only thing that you have real direct control over is the buffer size,
> and your
> low limit for that is when it won't record or play back reliably. And
> that's at least
> somewhat a function of the computer hardware, but I'm wondering how much,
> or if it's mostly about other stuff that's running at the same time as the
> DAW and
> taking its attention away from doing what you want it to do.
That's what multi-core sytems are for, and yes it makes a big difference. My
old single core system wasn't that much slower, but there's no way I could
get down to a 32 sample buffer without drop-outs. Not sure I'd want to
record 12 tracks at once like that - bigger buffers cost nothing unless you
are monitoring like this.
>> The other big issue is whether the DAW software uses multi-threading to
>> take advantage of the multiple cores. None of the old/cheap/free stuff I
>> use does, but if I eventually get around to upgrading that will be high
>> on my list to look for: at least the ability to run VST plugins across
>> all the cores.
>
> I don't know anything about mult-threading other than the term. If a
> plug-in had
> essentially its own CPU to run in, that seems like it would take a load
> off the
> CPU that's running the DAW program, and allow you to reduce the buffer
> size,
> therefore reducing the latency.
That's basically how it acts.
A thread is another execution path in the same program - it's like having
additional processes within a program, and it can be run on a different core
or CPU to run in parallel. For example, let's say you wanted to increase the
volume of a file, it would be possible with multi-threading to split the
file into however many cores you have, and spawn a thread for each piece to
do the work in parallel.
Of course it can only execute in parallel if you have a CPU that supports
it - hyper-thread, multi-core, multiple CPU's or some combination of these.
On a single core the overhead of switching between threads will actually
reduce the performance. Nowadays it's hard to find a system that doesn't
have some kind of multi-processing, so it's common for developers to assume
that it will be there, and that the OS will figure out the best way to
spread the threads across the cores.
The important point is that a single threaded program can *never* run on
more than one core at a time.
Hope this helps,
Sean
Mike Rivers
>> Of course the latency is still there, it's just that when the file is
>> saved, the time stamp
>> (and hence its position) is adjusted by the amount of time that the driver
>> sends to
>> the DAW program.
>
> It's not a value I can set - I think it just records that the input stream
> started at the moment I punched in, regardless of when the data started
> arriving.
Well, why didn't I think of that? It's certainly simpler than getting
what might
be bogus data from the driver. In Nuendo, though, it tells me how much
offset
the latency compensation is, and in Sonar, you actually patch the output
to the
input while it runs a test to determine the actual latency.
> That's what multi-core sytems are for, and yes it makes a big difference. My
> old single core system wasn't that much slower, but there's no way I could
> get down to a 32 sample buffer without drop-outs.
Even if you weren't running any plug-ins? I wonder if in general CPU tasks
are shared among processors. That could be a can of worms if you can't
control what's running on which processor when you're trying to do real time
operations. But then, nobody ever said that Windows was appropriate for
real time operation, it's just that if they make the computer fast
enough, it
doesn't matter.
> Not sure I'd want to
> record 12 tracks at once like that - bigger buffers cost nothing unless you
> are monitoring like this.
Exactly - so the way to avoid latency and still have solid performance
is to not
monitor through the DAW. But they build 'em that way, so there are plenty of
people who will want to do it, mostly saying that they don't have the
space or
money for dedicated hardware.
> A thread is another execution path in the same program - it's like having
> additional processes within a program, and it can be run on a different core
> or CPU to run in parallel. For example, let's say you wanted to increase the
> volume of a file, it would be possible with multi-threading to split the
> file into however many cores you have, and spawn a thread for each piece to
> do the work in parallel.
I guess I'd have to know more about computer science to understand that.
> On a single core the overhead of switching between threads will actually
> reduce the performance.
That's probably why the Windows optimizing-for-audio tips tell you to
turn off
hyper-threading unless you have multiple processors.
Laurence Payne
wrote:
Well, if you go into a digital system and out again, there's going to
be SOME latency. The only place it can't be compensated for is when
monitoring an input. Everywhere else compensation is possible, and
today's DAW software is pretty good at doing it.
You're not going to get it down to zero. But it's trivial to bypass
it altogether.
Apart from that, maybe the computer writes to disk "right now", maybe
it buffers massively and writes later. Who cares?
Sean Conolly
> Sean Conolly wrote:
>
>>> Of course the latency is still there, it's just that when the file is
>>> saved, the time stamp
>>> (and hence its position) is adjusted by the amount of time that the
>>> driver sends to
>>> the DAW program.
>>
>> It's not a value I can set - I think it just records that the input
>> stream started at the moment I punched in, regardless of when the data
>> started arriving.
>
> Well, why didn't I think of that? It's certainly simpler than getting what
> might
> be bogus data from the driver. In Nuendo, though, it tells me how much
> offset
> the latency compensation is, and in Sonar, you actually patch the output
> to the
> input while it runs a test to determine the actual latency.
Yeah, there's lots of ways to approach that problem. I like the idea that if
you hit 'record', you probably meant 'now'.
>> That's what multi-core sytems are for, and yes it makes a big difference.
>> My old single core system wasn't that much slower, but there's no way I
>> could get down to a 32 sample buffer without drop-outs.
>
> Even if you weren't running any plug-ins? I wonder if in general CPU tasks
> are shared among processors. That could be a can of worms if you can't
> control what's running on which processor when you're trying to do real
> time
> operations. But then, nobody ever said that Windows was appropriate for
> real time operation, it's just that if they make the computer fast enough,
> it
> doesn't matter.
No, every modern OS I've used is pretty good at handling this stuff. It's
not as simple as dedicating a core to a thread/process. The OS knows what
threads are blocked on something and which ones are ready to go, and assigns
them to a core as needed. Usually very few processes/threads are really
taxing the CPU, so it's mostly just an issue of scheduling threads around
I/O blocks.
>> Not sure I'd want to record 12 tracks at once like that - bigger buffers
>> cost nothing unless you are monitoring like this.
>
> Exactly - so the way to avoid latency and still have solid performance is
> to not
> monitor through the DAW. But they build 'em that way, so there are plenty
> of
> people who will want to do it, mostly saying that they don't have the
> space or
> money for dedicated hardware.
My personal choice is to use hardware - like a mixer - whenever it can do
the job. There are cases like running VSTi plugins where the sound has to be
rendered by a CPU, and there is no easy alternative short of using dedicated
hardware like a UAD card to offload the plugin. Thats when all of this
latency becomes a real concern - when the player hits a key they need to
hear a sound in human realtime - i.e. latency in single digit milliseconds.
I really need to try this out myself, but that's a whole new learing curve
to tackle.
>> A thread is another execution path in the same program - it's like having
>> additional processes within a program, and it can be run on a different
>> core or CPU to run in parallel. For example, let's say you wanted to
>> increase the volume of a file, it would be possible with multi-threading
>> to split the file into however many cores you have, and spawn a thread
>> for each piece to do the work in parallel.
>
> I guess I'd have to know more about computer science to understand that.
It's not that hard to understand, I'm just not too good at trying to explain
this stuff in writing. All I can say is that I write programs that take
advantage of multiple cores, so I have to assume that any good application
can do at least as good as I can.
>> On a single core the overhead of switching between threads will actually
>> reduce the performance.
>
> That's probably why the Windows optimizing-for-audio tips tell you to turn
> off
> hyper-threading unless you have multiple processors.
Well, maybe. There's a lot of single threaded programs out there that will
definitely run better without hyperthreading (A.K.A. making a single core
act like two cores). With a true multi-core CPU you just let it run. That
said, one of the reasons I chose a dual core instead of a quad core is so
the many single threaded programs I have will run better. And they do run
quite well.
You know, you shouldn't have to know this much about what's going on under
the covers to make music. It just seems that as soon as you involve a
computer, with any task, you end up having to know more than you wanted to
just to get the job done.
Sean
Mike Rivers
> Well, if you go into a digital system and out again, there's going to
> be SOME latency. The only place it can't be compensated for is when
> monitoring an input. Everywhere else compensation is possible, and
> today's DAW software is pretty good at doing it.
OK, so how do you minimize input monitoring latency, assuming that you
can't (or won't spend the money or commit the space) bypass it? Probably
anything you can do will help a measurable amount, but what's perceived
as significant and what's not?
Faster computer?
More memory?
Faster disk drive?
Different operating system?
Driver written by someone who knows more or has optimized it?
Reducing the buffer size is an obvious approach, but there's a limit to
how much that can be reduced. So assuming that's a worthwhile
approach, what, from the above list or anything else you might think
of will allow you to reduce the buffer size without affecting the recording
or playback performance?
> You're not going to get it down to zero. But it's trivial to bypass
> it altogether.
But you obviously can get it down to the point where at least some people
can work with it, and some people can't get it down to the point where it's
comfortable or even possible for them to work.
And don't trivialize the ability to bypass through-the-computer
monitoring. It's
easy to say (and I've said to people before) that if they can't afford the
capabilities of a real studio, they shouldn't be attempting to record in a
makeshift studio. I don't know how many times I've suggested to someone
that he get a simple and inexpensive mixer for monitoring and there's always
an excuse or three, mostly having to do with space and money.
Further, you can't just get away with saying "get a mixer" to most of these
people. Even if they were willing to spend the money, they wouldn't have
any idea of what to do with it. They need a wiring diagram and full
instructions,
and they want it free and on line. Ethan Winer (among others) published an
article in a magazine years ago, and it's on his web site, detailing a
simple
approach. Even with everything they need to know right in front of them,
many people still don't get it.
And then there's the other problem of virtual instruments. There's no way
to play a virtual instrument and hear it unless you monitor the output from
the computer. My solution to that is to record the data and listen to
something
else while you're putting down the part, but to someone trying to get away
as cheaply as possible, or to someone to whom a particular sound is
inspiring,
I thought I was asking the right questions here. Maybe I'm asking the wrong
group. But I don't want to ask someone who could (and maybe did) rewrite
buffers or the operating system, I want to know what has been tried, what's
been successful, and what hasn't.
> Apart from that, maybe the computer writes to disk "right now", maybe
> it buffers massively and writes later. Who cares?
Anyone who isn't having success setting up a recording system might care.
Disk buffering used to be an issue 20 years ago, but nobody has said
anything about it for quite some time.
Mike Rivers
> No, every modern OS I've used is pretty good at handling this stuff. It's
> not as simple as dedicating a core to a thread/process. The OS knows what
> threads are blocked on something and which ones are ready to go, and assigns
> them to a core as needed. Usually very few processes/threads are really
> taxing the CPU, so it's mostly just an issue of scheduling threads around
> I/O blocks.
Is 'pretty good' good enough so that there isn't a significant
difference between
Windows, MacOS, Linux, or even a dedicated, closed OS like in the Mackie
hard disk recorders? The Mackie HDR24/96, bless its soul, is as close as
you
can come to analog tape deck relay switching for monitoring without
relays or
analog switching. When you're in Input Monitor mode, the routing from
input to
output is done before the data hits the computer. This is essentially
the same
as a computer audio interface with DSP monitoring. But still, there's no
virtual instrument plug-in for the HDR24/96.
> My personal choice is to use hardware - like a mixer - whenever it can do
> the job. There are cases like running VSTi plugins where the sound has to be
> rendered by a CPU, and there is no easy alternative short of using dedicated
> hardware like a UAD card to offload the plugin.
Agreed. But again, that's a fairly expensive hardware solution, it only
solves
a particular problem, and it's not as close to universal as running
everything
through the computer. There is a limited set of plug-ins for any given
DSP card.
I don't know why nobody's designed a general purpose DSP card that anyone
with the development kit can write for. I guess it's to make money
selling cards
and software rather than making money just selling one or the other.
> Thats when all of this
> latency becomes a real concern - when the player hits a key they need to
> hear a sound in human realtime - i.e. latency in single digit milliseconds.
> I really need to try this out myself, but that's a whole new learing curve
> to tackle.
And there are new people fumbling with it every day . . and it's almost
Christmas!
> All I can say is that I write programs that take
> advantage of multiple cores, so I have to assume that any good application
> can do at least as good as I can.
That's the nut that few if any seem to have cracked. Same with drivers
(though
for a different reason). For example, RME says they don't write their
drivers
like everyone else, perhaps because they don't build their hardware like
everyone
else. But the bottom line is that people switching from, say, a MOTU
interface to
an RME interface, using the same computer and OS, seem to get lower latency,
however they're perceiving latency. But "Get an RME" is about as useful
advice
to someone with no money left than "Get a mixer."
> Well, maybe. There's a lot of single threaded programs out there that will
> definitely run better without hyperthreading (A.K.A. making a single core
> act like two cores). With a true multi-core CPU you just let it run.
But ultimately, isn't the operating system directing the traffic? Or is
the multi-core
CPU smart enough so that it has a single input and shoves whatever comes
into
that input off to a worker who has time to take care of it? And then
hopefully
spits it out sooner than if it waited its turn for a single processor?
> You know, you shouldn't have to know this much about what's going on under
> the covers to make music. It just seems that as soon as you involve a
> computer, with any task, you end up having to know more than you wanted to
> just to get the job done.
Yup, you've got that exactly right. And most of us don't WANT to learn
very much
about computers. And we wouldn't have to if the people who supply us
with our
audio hardware and software (and our computers, too) did the optimizing
for us.
But in most cases they don't. The user is left to be his own system
engineer, fixing
the hardware and the software until it does a good enough job for him,
which may
not be good enough for you, or me, or the other guy. It was so much
easier to get
a hassle-free system when the buy-in for a reasonably equipped recording
studio
was $50,000 just for the equipment. For $500, it's not unreasonable to
expect
some compromises, but it's hard to convince the struggling (with his day
job, his
music, his computer, and his budget) musician of that.
John Watkinson wisely said: "Today's production equipment is IT based and
cannot be operated without a passing knowledge of computing, although it
seems
that it can be operated without a passing knowledge of audio."
Jay Ts
> I'm way behind on my practical computer experience, but I'm trying to
> gather some usable data on just what affects latency in a digital audio
> path significantly, and what affects it theoretically (everything does,
> I know) but by an insignificant amount relative to the total delay time.
Mike, you've asked a question that isn't just about "practical computer
experience." A detailed explanation requires understanding of operating
system design and construction. Things like interrupt handling, real-
time performance, how device drivers, OS kernels, and hardware interact,
kernel scheduling algorithmms, and things like that.
I'm not up-to-date with current OS and hardware designs, and it would
still take me a chapter of a book to explain what I do understand.
As others have said, it may be a better to skip the details, and
focus on using the technology -- take a Gordion's Knot approach,
and if your system is not performing up to your needs, get a faster
CPU, make sure you have enough memory, and tweak your system to
avoid problems. Keep it simple, and don't get bogged down by details.
Now having said that, I'll see if I can respond to some of your
questions...
> What about what goes on inside the computer? Given that the DAW program
> and operating system can take advantage of it, does a quad-core CPU turn
> around the data significantly faster than a single core one? Or
> does having gobs of RAM make a difference?
I'm not an expert on this, and I think you've already gotten a
response from someone who knows more than I. But, I would suggest
getting a dual-core CPU at least. The reason is to allow your main
audio app to have one of the cores, and allow the other to handle
other odd stuff that comes up from time to time needing a sudden
dose of CPU power.
The reason is that audio apps have to stay caught up with the
audio hardware and device driver(s). If they don't, the buffer
will overflow, and you will get pops. Usually, what people do
is to increase the buffer size, and that adds latency.
If your CPU and applications are fast enough, you can use a smaller
buffer. But you need to make sure there isn't anything that will
happen that distracts the CPU from the audio app for very long. There
a number of things that could conceivably do this, such as other
applications/tasks that are consuming huge percentages of the CPU.
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. On Linux, I *think*
this is much less of a problem, because device driver writers are
instructed to absolutely avoid writing drivers that way, and there
is a mechanism to allow device drivers to do only the most essential
operations at high priority, and schedule the rest of the work for
later. But I don't know enough about the Windows and OS X device
driver models to give a real comparison.
About adding "gobs of RAM", I think all of Linux, Windows and OS X
all will benefit from more memory. It helps if the OS kernel has
more space to play in. But, 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.
Just make sure you have more than enough RAM for the system to
function smoothly, and you will be fine. 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.
> Since most all driver "control panels" allow you to set buffer size,
> this is going to
> have a large, probably the largest, effect on latency. The advice to
> reduce the
> buffer size until recording becomes unreliable, and then jack it back up
> is well
> known. Almost as well known is that different systems will choke at
> different
> buffer sizes, and that this can usually be optimized by making the
> computer less
> busy.
Yes, or get a faster CPU. ;) Or an audio device with more efficient
device drivers, or disable naughty device drivers ... etc., etc.
> And how about hard drive throughput? Is the difference between 5400,
> 7200, and
> 10,000 RPM significant with modern drives? How about the difference
> between EIDE/ATA-133 and SATA?
These issues really don't matter much. 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.
And in any case, it's not a latency issue, it's a hardware performance
issue.
> Now, about another kind of latency that's a matter of concern for many -
> playing virtual
> instruments inside a DAW, generally VST plug-ins. Where are the
> significant bottlenecks
> between the time you press a key and when you hear a sound? Does
> everything these
> days get played out of RAM, so disk access and throughput speed doesn't
> affect this delay?
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
(e.g., Kontakt, Halion, E-mu's Proteus X2 and Emulator X[23], and
many others. This technology has been around for a long time.
Gigasampler was first released 10 years ago.
Basically, the sampler loads the initial moments of each sample
into memory, so it can start playing the sounds "immediately",
without having to wait for a disk access. While it's doing that,
it loads more of the sound data from the disk, so it will never
run out of data, and can play samples that are limited by disk
space, not memory.
Disk access speed does matter, but again, it's a harware performance
issue, not a latency issue. If you have a faster disk subsystem,
you can play more voices at once.
As for other kinds of virtual instruments, as far as I know, the
answer is, "It depends." Any instrument will have to create the
sound in its own internal buffer before handing it over to the
operating system and device driver. So there's always going
to be at least a little latency. How it does that is very dependent
on the design of the specific virtual instrument application.
Now, addressing the issue of "between the time you press a key and when
you hear a sound" ... that again is getting into many details, and the
complexity of how hardware, OS kernels, and device drivers function.
Pressing a key generates a MIDI event, and the system has to respond
to that. Whatever application or task that currently has the attention
of the CPU needs to be interrupted, it's state saved, so it can be
restored and continued later. Then the kernel handles the event, and
hands off control to the device driver. Which may do a little work
during that high-priority exception processing, and then schedule the
rest of the job for later. Eventually, the OS is able to deliver the
MIDI event to the application, which has to be scheduled, and once
it is running again, it can then look at the MIDI event and decide
what to do. And then it takes a short while to construct a waveform to
send to the audio device driver, and then the kernel has to go through
the exception processing again to get the data out. The difference is
that the audio I/O is buffered, so instead of sending a sample at a time,
a large number is sent. So there is the latency caused by the time
difference between sending the first and last (latest) samples in the
buffer.
As far as latency is concerned, the worst part of all this is
that the latency involved in responding to I/O is not constant.
The extreme case being what I pointed to earlier, a greedy device
driver that doesn't want to give up the CPU to anyone else until
it's done. There is no way to get around this variability, and even
if you move to a so-called "real-time" operating system, the only
thing you get is a guarantee of the maximum time it will take to
respond (which in itself is a good thing). And getting a faster
system will lower the slowest response time, so you can also just
do that.
That was pretty complicated, and it's just a VERY rough overview
of the entire process. But maybe now you can understand enough
that if you want, you can do some searches to learn more from
online resources. There is information on writing Linux device
drivers, at least. A suggested starting place is this Wikipedia
article on device drivers:
http://en.wikipedia.org/wiki/Device_driver
The other scenario you asked about (microphone in to headphones out)
is similar, except that you are doing buffered audio I/O on both
the inputs and outputs.
> I'm trying to get past the obvious "get the fastest system you can and
> optimize it" and
No, don't try to get past that. Just do 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.
Jay Ts
--
To contact me, use this web page:
http://www.jayts.com/contact.php
Laurence Payne
wrote:
>> You're not going to get it down to zero. But it's trivial to bypass
>> it altogether.
>
>But you obviously can get it down to the point where at least some people
>can work with it, and some people can't get it down to the point where it's
>comfortable or even possible for them to work.
Well, that's my point. You don't need any special tweaking or
esoteric hardware these days to achieve less than 10ms latency through
the system with effects, or a couple of ms "direct". That's fine for
most situations and most people. Those who ARE sensitive to 2ms
delay aren't going to be much happier with 1.5ms. So spend �30 on a
Behringer mixer and make them happy.
Mike Rivers
> Mike, you've asked a question that isn't just about "practical computer
> experience." A detailed explanation requires understanding of operating
> system design and construction. Things like interrupt handling, real-
> time performance, how device drivers, OS kernels, and hardware interact,
> kernel scheduling algorithmms, and things like that.
By asking for practical computer experience, I don't mean designing an
operating
system, I mean about using the tools available to a normal (hence
"practical")
computer user. We know that we can improve recording performance, that is,
skipping and clicking, by doing things like disabling functions that are
constantly
interrupting the job at hand like screen saver, CD-inserted checker,
virus scanner,
networking, indexing, and so on.
> As others have said, it may be a better to skip the details, and
> focus on using the technology -- take a Gordion's Knot approach,
> and if your system is not performing up to your needs, get a faster
> CPU, make sure you have enough memory, and tweak your system to
> avoid problems. Keep it simple, and don't get bogged down by details.
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? Surely
it can't hurt, but how much will it help? And in what way?
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?
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? Again, how much? If it's working at 256 samples with the old
computer,
will the new computer allow it to be set to 32 samples and still get the
same
glitch-free performance? Or does it start to choke with the buffer
smaller than, say
192 samples?
In other words, is it hopeless to try to significantly improve latency
by "improving"
the computer?
> I would suggest
> getting a dual-core CPU at least. The reason is to allow your main
> audio app to have one of the cores, and allow the other to handle
> other odd stuff that comes up from time to time needing a sudden
> dose of CPU power.
Let's continue the game. That's probably good advice for someone
starting out with
the intent of buying a computer for the purpose (though I didn't take
that advice myself
when I got a P4 when dual core CPUs were fairly common, though at more
than double
the cost for the whole ready-to-go box than what I paid). But suppose
like most
people who go into this - getting a new computer isn't an option.
> The reason is that audio apps have to stay caught up with the
> audio hardware and device driver(s). If they don't, the buffer
> will overflow, and you will get pops. Usually, what people do
> is to increase the buffer size, and that adds latency.
Exactly. So you're saying that a faster computer will allow using a
smaller buffer.
I suspected that, but I'm trying to get a sense (from practical
experience) of just
how much difference a given "improved" configuration can make here.
> But you need to make sure there isn't anything that will
> happen that distracts the CPU from the audio app for very long. There
> a number of things that could conceivably do this, such as other
> applications/tasks that are consuming huge percentages of the CPU.
This is what's usually referred to as "optimizing" the computer for audio.
> 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? 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.
> 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.
> 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?
> Yes, or get a faster CPU. ;) Or an audio device with more efficient
> device drivers, or disable naughty device drivers ... etc., etc.
Get, get, get . . . How about fixing what you got? Possible or not? That's
the question.
> 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.
> And in any case, it's not a latency issue, it's a hardware performance
> issue.
And one that won't be improved by doing any of the things that can reduce
latency.
> 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? Does
it have to do with the VST system, as most use? I think
you just answered that:
> Any instrument will have to create the
> sound in its own internal buffer before handing it over to the
> operating system and device driver. So there's always going
> to be at least a little latency. How it does that is very dependent
> on the design of the specific virtual instrument application.
.... good stuff about the process of getting from a key press to
a sound out to the speaker ....
> That was pretty complicated, and it's just a VERY rough overview
> of the entire process. But maybe now you can understand enough
> that if you want, you can do some searches to learn more from
> online resources.
So some virtual instruments are better than others. This is a good
justification for my recommendation that when tracking with a virtual
instrument, you listen to a sound generated in hardware so you know
what you're doing, then listen to the playback (after "latency
compensation")
to hear it with the instrument you think your really want. 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. That's probably going to mean
"get a better instrument." Or will "get a faster computer" help in this
instance?
> 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." 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.
Laurence Payne
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? Surely
>it can't hurt, but how much will it help? And in what way?
An underpowered computer may limp along better with higher buffer
settings (and hence higher latency). But I think, once you get to a
certain level (and not a particularly high one by today's standards)
sufficient is sufficient. If you're using sample-playing virtual
instruments, enough RAM to cache the sounds a project will use is a
very good idea. If you're working just with audio tracks, the aim is
to REDUCE buffer size, not increase it! What would excess RAM be
used for? Anyway, audio buffers are measured in KB, not MB or GB.
Mike Rivers
> An underpowered computer may limp along better with higher buffer
> settings (and hence higher latency). But I think, once you get to a
> certain level (and not a particularly high one by today's standards)
> sufficient is sufficient.
This is what I suspected, but I was hoping to get some confirmation. I sort
of do, from people who have had performance problems requiring fairly
large buffer settings to overcome, who have had mighty powerful computers.
Trouble is that many of those computers (and users) are new, so they
haven't had time to work through the issues. They're either hoping that
it will work perfectly right out of the box (and really, it SHOULD), or that
there's a cookbook or checklist that they can follow to "fix" their own
computer.
I don't know what a new Mac is like, but a new Windows computer from
the local WalMart or Staples (where else do people get computers
today?) is gooked up with a lot of stuff that can get in the way of
efficient
audio processing. And even if you assemble your own computer from
components of your (hopefully well informed) choosing, if you install
the OS from a retail version of Windows, unless you know more than I
do, you'll end up installing a lot of the same stuff that the appliance
store
computers have.
> very good idea. If you're working just with audio tracks, the aim is
> to REDUCE buffer size, not increase it! What would excess RAM be
> used for? Anyway, audio buffers are measured in KB, not MB or GB.
I usually see it written as samples or milliseconds, which would indeed
require kilobytes rather than megabytes.
Michael Dobony
Single, dual, and quad core can mean nothing if the OS and software cannot
take advantage of multiple cores/processors. Then you also have a potential
problem of "hickups" in OS or SW. For instanc, OEM Vista on my laptop locks
up for a few seconds very often. W7 less so. XP rarely. In this case
latency can be several seconds, not ms.
>
> Since most all driver "control panels" allow you to set buffer size,
> this is going to
> have a large, probably the largest, effect on latency. The advice to
> reduce the
> buffer size until recording becomes unreliable, and then jack it back up
> is well
> known. Almost as well known is that different systems will choke at
> different
> buffer sizes, and that this can usually be optimized by making the
> computer less
> busy.
>
> And how about hard drive throughput? Is the difference between 5400,
> 7200, and
> 10,000 RPM significant with modern drives? How about the difference between
> EIDE/ATA-133 and SATA?
>
HD speed only comes into play if you are using virtual memory. This can be
handled by gobs of memory and a 64 bit OS that can handle >3gb ram.
Michael Dobony
> Laurence Payne wrote:
>
>> An underpowered computer may limp along better with higher buffer
>> settings (and hence higher latency). But I think, once you get to a
>> certain level (and not a particularly high one by today's standards)
>> sufficient is sufficient.
>
> This is what I suspected, but I was hoping to get some confirmation. I sort
> of do, from people who have had performance problems requiring fairly
> large buffer settings to overcome, who have had mighty powerful computers.
> Trouble is that many of those computers (and users) are new, so they
> haven't had time to work through the issues. They're either hoping that
> it will work perfectly right out of the box (and really, it SHOULD), or that
> there's a cookbook or checklist that they can follow to "fix" their own
> computer.
>
> I don't know what a new Mac is like, but a new Windows computer from
> the local WalMart or Staples (where else do people get computers
> today?) is gooked up with a lot of stuff that can get in the way of
> efficient
> audio processing. And even if you assemble your own computer from
> components of your (hopefully well informed) choosing, if you install
> the OS from a retail version of Windows, unless you know more than I
> do, you'll end up installing a lot of the same stuff that the appliance
> store
> computers have.
Not so. Most retail bought computers have manufacturer utilities that bog
down a system that are not found on retail versions of Windows. Retail
versions of windows do not have samples of Office, accounting software,
additional games, utilities, anti-virus, etc.
If I was to use a computer as you seem to be suggesting I would custom
build it and remove all non-essential programs and utilities and never hook
it up to the net, foregoing the need for any anti-virus SW. It would be a
dedicated computer for doing nothing but sound.
Mike Rivers
> Most retail bought computers have manufacturer utilities that bog
> down a system that are not found on retail versions of Windows. Retail
> versions of windows do not have samples of Office, accounting software,
> additional games, utilities, anti-virus, etc.
Unless those things are loaded at startup, it's really only the
anti-virus software
that continuously digs around on the disk and in memory looking for
something
to warn you about. I don't know how much memory having a program on the
start
bar takes, but for things like Office, it's not doing anything unless
you're doing
something in the program.
My IBM laptop had all sorts of stuff on it that ran on startup that I
didn't know
what it was, some identified (with a Google search) as IBM utilities,
some still
unidentified after close to four years with that computer. I just turned
them off
and don't think I ever missed any of them.
> If I was to use a computer as you seem to be suggesting I would custom
> build it and remove all non-essential programs and utilities and never hook
> it up to the net, foregoing the need for any anti-virus SW. It would be a
> dedicated computer for doing nothing but sound.
That's always good advice, but again, I reiterate - the majority of
people who
buy audio hardware and software for the purpose of recording do it to record
themselves because they can, with very little money. Very few buy a computer
exclusively for that purpose but use the computer that they use every
day. For
those people, the advice is to look for things that they can turn off
and do it.
Those are things that are under your control without much extra cost, space,
or inconvenience.
Does Vista and Win7 have MSCONFIG and SERVICES.MSC like WinXP does?
If not, where do you send people to find services, processes, and
programs that
are running and can be turned off?
Any good "optimizing for audio" web sites for the newer operating
systems yet? And
do you have to worry about any of that with a Mac? Sorry for getting off
the direct
topic of latency, but it seems that the most effective answer to my
question about reducing
latincy is to make the computer able to run with a smaller buffer.
Laurence Payne
wrote:
>I don't know what a new Mac is like, but a new Windows computer from
>the local WalMart or Staples (where else do people get computers
>today?) is gooked up with a lot of stuff that can get in the way of
>efficient
>audio processing. And even if you assemble your own computer from
>components of your (hopefully well informed) choosing, if you install
>the OS from a retail version of Windows, unless you know more than I
>do, you'll end up installing a lot of the same stuff that the appliance
>store
>computers have.
Not really. The store-bought computer will probably have a lot more
than Windows installed. There'll be a version of Norton or McAfee,
waiting to suck money from you after the "free" trial period. Maybe a
background application servicing a pretty row of dedicated extra keys,
most of which merely duplicate a simple click on a desktop icon. And
maybe some more useful utilities, which won't do you any harm unless
you try to run them WHILE also running a DAW application.
Speaking of Norton etc., are we all aware of Microsoft Security
Essentials? This free download for Windows is the anti-virus and
anti-spyware that should have been part of Windows from day 1, but
apparently was prevented by cries of "unfair completion" from other
companies. I don't know how they got round this issue (is Windows 7
still being sold in some territories with Internet Explorer unbundled
for the same reason?) but it's there and reportedly does what it says
on the can.
Laurence Payne
<sur...@stopassaultnow.net> wrote:
>Not so. Most retail bought computers have manufacturer utilities that bog
>down a system that are not found on retail versions of Windows. Retail
>versions of windows do not have samples of Office, accounting software,
>additional games, utilities, anti-virus, etc.
>
>If I was to use a computer as you seem to be suggesting I would custom
>build it and remove all non-essential programs and utilities and never hook
>it up to the net, foregoing the need for any anti-virus SW. It would be a
>dedicated computer for doing nothing but sound.
It's only the background-running stuff that you really need to worry
over. An exe file just sitting there waiting to be executed isn't
going to jump up and bite you on the bum.
Sean Conolly
> Does Vista and Win7 have MSCONFIG and SERVICES.MSC like WinXP does?
> If not, where do you send people to find services, processes, and programs
> that
> are running and can be turned off?
I'm sure there's something that fills those roles, but MS likes to change
how you get to them on every version of Windows.
> ... but it seems that the most effective answer to my question about
> reducing
> latincy is to make the computer able to run with a smaller buffer.
And picking a decent platform in the first place. Buying an older system
built for gaming can be affordable and will run a lot better than a brand
new WallMart system, even with the same CPU and RAM.
I built my current system back in the spring, and used the stuff the gamers
considered good a couple of years ago. It works very well for audio and the
only reason the price hit the $700 mark was because I bought an Antec Sonata
case for additional noise control.
But I don't know of specific tweaks for anything newer than XP. I'm
deliberately using an older OS because it's fast and lean.
Sean
Les Cargill
> I'm way behind on my practical computer experience, but I'm trying to
>
> What about what goes on inside the computer? Given that the DAW program
> and operating system can take advantage of it, does a quad-core CPU turn
> around the data significantly faster than a single core one? Or does having
> gobs of RAM make a difference?
A device or device driver will "bundle" sets of samples
together in order to amortize the interrupt cost over
more samples - leading to the 1.5msec figure you used above. How
much latency depends, which is why good DAW programs allow
you to tune this.
This is both outgoing and incoming - so if it's 1000 samples
that's 2000 samples' worth of delay
Beyond that, the DAW program itself has no reason other than to go
sample-by sample. So ideally, you should be able to expect no
latency other than driver latency. That's the general case. Then
come the exceptions...
When you code a VST plugin, it's all coding up what's affectionately
referred to as a "callback", on exactly one sample at a time. But
plugins such as the free version of SIR ( for reasons I don't fully
understand - it has to do with simulating brute force convolution
using FFT ) have a fixed latency of <n> samples. The plugin must
provide the context for any effect locally - such as the xv[] and
yv[] vectors as well as the coefficients for the 'C' code generated from
here: http://www-users.cs.york.ac.uk/~fisher/mkfilter/trad.html )
Those filters also have a one-deep sample context, and unless the
filter has an inherent latency, no additional latency should be
in play.
Dual core, single core, more RAM... no. Those should have no
effect on actual measurable latencies, excepting to reduce
the probability of a page file swap or something equally unpleasant.
Adding more processors makes latency problems worse - generally,
for general-purpose computers, and especially for shrinkwrap
software that must run on anything it's thrown at. Maybe you
get use of it to your advantage, maybe not.
On my 3.06GHz P4, I use 0.116 seconds of buffering, way more
than I can achieve anything like realtime monitoring with. Could I use
less? Probably. But not enough to not need an external monitoring mixer.
What that 0.116 gives me is pretty close to 100% probability of never
missing an interrupt from the soundcard. For a variety of reasons,
I can't use ASIO drivers, yadda yadda. Even when I suffer through ASIO
enough to get it to work, latencies are clearly audible.
But it's a recorder, not a realtime f/x box.
--
Les Cargill
Laurence Payne
<sjcono...@yaaho.com> wrote:
>"Mike Rivers" <mri...@d-and-d.com> wrote in message
>news:hetlt5$iq4$1...@news.eternal-september.org...
>> Does Vista and Win7 have MSCONFIG and SERVICES.MSC like WinXP does?
>> If not, where do you send people to find services, processes, and programs
>> that
>> are running and can be turned off?
>
>I'm sure there's something that fills those roles, but MS likes to change
>how you get to them on every version of Windows.
You can hit <windows>-R to get the Run box, then type in
"services.msc". Or you can r-click "Computer" and choose Manage.
>> ... but it seems that the most effective answer to my question about
>> reducing
>> latincy is to make the computer able to run with a smaller buffer.
You can always choose your own buffer size. Tweaks MAY allow you to
choose a smaller one without clicks, pops or even instability.
But be clear we're talking about the latency of data being processed
through your DAW's engine. The latency that affects real-time playing
of virtual instruments and monitoring of an audio input with effects.
You can't tweak the couple of ms taken to get the signal in through
the ADC then out again through the DAC. This is pretty well built in
to your soundcard's hardware. (Just like the inevitable spacing of
the third head was on a tape system.)
>And picking a decent platform in the first place. Buying an older system
>built for gaming can be affordable and will run a lot better than a brand
>new WallMart system, even with the same CPU and RAM.
But be careful. Gamers need different things to us. A gaming machine
may well be a quite ordinary computer, overclocked (and therefore
cooled) to its limits, and equipped with a powerful video card (which
will likely be responsible for a lot of the price, have noisy fans and
require a lot of resources). We don't need any of that.
>I built my current system back in the spring, and used the stuff the gamers
>considered good a couple of years ago. It works very well for audio and the
>only reason the price hit the $700 mark was because I bought an Antec Sonata
>case for additional noise control.
>
>But I don't know of specific tweaks for anything newer than XP. I'm
>deliberately using an older OS because it's fast and lean.
Obviously don't mess with a working system. But I suspect you won't
be too unhappy if your next computer comes with Windows 7.
Les Cargill
> Sean Conolly wrote:
>
>
> I don't know anything about mult-threading other than the term. If a
> plug-in had essentially its own CPU to run in, that seems like it would take a load
> off the CPU that's running the DAW program, and allow you to reduce the buffer
> size, therefore reducing the latency.
>
> Somebody must have experimented with this.
Coordination overhead exceeds the benefit in throughput,unless you can
design down to specialized hardware. You'd have to maintain plugin
context across multiple "machines". *Can* it be done? I'm sure it can.
Will somebody build a machine to do it? Dunno.
Nine women cannot have a baby in one month. It's like that...
--
Les Cargill
Les Cargill
<snip>
>
> This is what I suspected, but I was hoping to get some confirmation. I sort
> of do, from people who have had performance problems requiring fairly
> large buffer settings to overcome, who have had mighty powerful computers.
> Trouble is that many of those computers (and users) are new, so they
> haven't had time to work through the issues. They're either hoping that
> it will work perfectly right out of the box (and really, it SHOULD), or
> that
> there's a cookbook or checklist that they can follow to "fix" their own
> computer.
>
> I don't know what a new Mac is like, but a new Windows computer from
> the local WalMart or Staples (where else do people get computers
> today?) is gooked up with a lot of stuff that can get in the way of
> efficient
> audio processing. And even if you assemble your own computer from
> components of your (hopefully well informed) choosing, if you install
> the OS from a retail version of Windows, unless you know more than I
> do, you'll end up installing a lot of the same stuff that the appliance
> store
> computers have.
>
http://www.revouninstaller.com/
>> very good idea. If you're working just with audio tracks, the aim is
>> to REDUCE buffer size, not increase it! What would excess RAM be
>> used for? Anyway, audio buffers are measured in KB, not MB or GB.
>
> I usually see it written as samples or milliseconds, which would indeed
> require kilobytes rather than megabytes.
--
Les Cargill
Mike Rivers
> You can always choose your own buffer size. Tweaks MAY allow you to
> choose a smaller one without clicks, pops or even instability.
OK, let's not go in circles here. Sure, you can choose your own buffer
size,
but the larger the buffer, the greater the latency, whether you need it
or not.
That's something that's easily verified with an experiment.
The question, again, is whether, for a given buffer size, you can affect
the latency significantly by changing things in the computer. I'm not
convinced
that you can. Perhaps make a change of a millisecond or so, but not 10 ms.
> But be clear we're talking about the latency of data being processed
> through your DAW's engine. The latency that affects real-time playing
> of virtual instruments and monitoring of an audio input with effects.
> You can't tweak the couple of ms taken to get the signal in through
> the ADC then out again through the DAC. This is pretty well built in
> to your soundcard's hardware.
Right. As is whatever time the driver takes to pass the data, and the DAW
program to spit it out. I think it's pretty well established that not
all manufacturers
have drivers that are equally fast. But you can't use an RME driver with
a Mackie
interface. You have to take what they give you.
Mike Rivers
> http://www.revouninstaller.com/
Man, that looks like it does what I've always wanted. Free, too. What's
the catch?
Laurence Payne
wrote:
>> But be clear we're talking about the latency of data being processed
>> through your DAW's engine. The latency that affects real-time playing
>> of virtual instruments and monitoring of an audio input with effects.
>> You can't tweak the couple of ms taken to get the signal in through
>> the ADC then out again through the DAC. This is pretty well built in
>> to your soundcard's hardware.
>
>Right. As is whatever time the driver takes to pass the data, and the DAW
>program to spit it out. I think it's pretty well established that not
>all manufacturers
>have drivers that are equally fast. But you can't use an RME driver with
>a Mackie
>interface. You have to take what they give you.
Phew! I think we're there at last:-)
What's this all about? Are you hoping to get an article out of the
subject?
Mike Rivers
> What's this all about? Are you hoping to get an article out of the
> subject?
Yes. I get tired of seeing the the question "Does it have low latency?"
asked about nearly any new sound card or audio interface that someone
hears about and have to ask "what latency are you talking about?" It
seems that most people don't know anything about it other than that low
is good.
Les Cargill
None that I'm able to find.
--
Les Cargill
Jay Ts
> 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
> Laurence Payne wrote:
>
>> You can always choose your own buffer size. Tweaks MAY allow you to
>> choose a smaller one without clicks, pops or even instability.
>
> OK, let's not go in circles here. Sure, you can choose your own buffer
> size,
> but the larger the buffer, the greater the latency, whether you need it
> or not.
> That's something that's easily verified with an experiment.
>
> The question, again, is whether, for a given buffer size, you can affect
> the latency significantly by changing things in the computer. I'm not
> convinced
> that you can. Perhaps make a change of a millisecond or so, but not 10
> ms.
I wrote about this separately, just a few minutes ago. But to be
clear about it, I will explain again.
On my laptop, a bad WiFi driver was causing 22 ms. of latency.
If I recall correctly, it was once per minute. If I tried to
work around that by increasing the buffer size, I got huge
latency, and it was absolutely unacceptable.
By disabling the WiFi driver and battery monitor driver, I made
the laptop useful for realtime audio, and now I am using a M-Audio
USB audio interface with 5 ms. of latency, which is near to its
minimum setting. (Sometimes I can use the minium of 2.5 ms.,
but varies with the application.)
Increasing the CPU speed in this case might not have helped.
The WiFi driver might easily have been inducing the 22 ms.
delays by intentionally waiting for 22 ms., no matter what
speed the processor is running at.
And even if I'm wrong about that, with this much of a problem,
spending a lot of money on a faster computer would be foolish,
when a simpler solution was so easily at hand.
After going through this experience myself, I cannot overstress
the importance of running the DPC Latency Checker, or similar
tool, especially on a laptop.
Just a few mouse clicks transformed the laptop from a demon into
a really cool toy.
Don Pearce
wrote:
Any wireless link will introduce latency. This is built into the error
correction system it must use - the order of bits is massively
jumbled, and you have to wait quite a while before you can start
assembling a complete byte, let alone a complete word. The more rugged
the error correction the worse this will be. A dedicated audio link
doesn;'t need much, but something like Wi Fi that has to transmit data
100% perfect is going to carry a lot of latency.
d
Scott Dorsey
>Any wireless link will introduce latency. This is built into the error
>correction system it must use - the order of bits is massively
>jumbled, and you have to wait quite a while before you can start
>assembling a complete byte, let alone a complete word. The more rugged
>the error correction the worse this will be. A dedicated audio link
>doesn;'t need much, but something like Wi Fi that has to transmit data
>100% perfect is going to carry a lot of latency.
His issue is that the wifi driver was stealing cycles and even when the
wifi link was not in use for moving data around, it was still causing
latency because it was commandering the CPU and could not be interrupted
by the OS.
This is just one of those things you live with when you try to do realtime
jobs without a realtime kernal.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arkansan Raider
Thanks!
---Jeff
Mike Rivers
> 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.
Laurence Payne
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. ;-)
I'd contradict that and say generally it's "no". Fast enough is fast
enough. And modern computers ARE fast enough.
Of course, as resources expand, people find ways to use them. You can
take any computer, set 192kHz sample rate, pile on multiple instances
of processor-hungry plugins and get it begging for mercy! Increasing
the buffer size may buy you a little more performance. But, until
the system gives up, latency will still be what you set it at.
Laurence Payne
wrote:
>
>On my laptop, a bad WiFi driver was causing 22 ms. of latency.
>If I recall correctly, it was once per minute.
What do you actually mean by that? Something froze up once a minute?
I'm not sure it's helpful to stretch the term "latency" to cover that,
though it could probably be justified from a dictionary :-)
Laurence Payne
wrote:
>> 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.
Isn't an elephant something everyone knows, but no-one admits?
Leaving that term aside - surely it's basic knowledge there's a user
setting for buffer size, and it defines the latency figure? What gets
overlooked is that effective latency isn't this buffer divided by
sample rate. You have to add the fixed figure from the "other"
delays. (This is the couple of ms in "direct monitoring" that Mike
definitely doesn't find insignificant in practice.) The buffering that
causes it is hard-wired into the soundcard architecture and its
drivers.
It's not inconceivable that a user could hack some of these settings.
Rather as we now have to tell Windows System Restore: "Yes, 15% of
the drive was a reasonable amount to use of a 60GB drive, but I think
we can specify rather less of a 1TB disk!", perhaps, on a really fast
computer, the fixed latency could be pared down a little. Or maybe
it's more about the soundcard hardware and should be left well alone.
Anyone else remember struggling to get Cubase Audio running on an
Atari Falcon? The driver that made this possible was unstable with
its default settings. Finding the undocumented setting that cured it
wasn't exactly hacking, but it felt like it in those days!
Michael Dobony
> Michael Dobony wrote:
>
>> Most retail bought computers have manufacturer utilities that bog
>> down a system that are not found on retail versions of Windows. Retail
>> versions of windows do not have samples of Office, accounting software,
>> additional games, utilities, anti-virus, etc.
>
> Unless those things are loaded at startup, it's really only the
> anti-virus software
> that continuously digs around on the disk and in memory looking for
> something
> to warn you about. I don't know how much memory having a program on the
> start
> bar takes, but for things like Office, it's not doing anything unless
> you're doing
> something in the program.
Office has an office bar that takes up resources. So does indexing, upgrade
schedulers, etc.
>
> My IBM laptop had all sorts of stuff on it that ran on startup that I
> didn't know
> what it was, some identified (with a Google search) as IBM utilities,
> some still
> unidentified after close to four years with that computer. I just turned
> them off
> and don't think I ever missed any of them.
>
>> If I was to use a computer as you seem to be suggesting I would custom
>> build it and remove all non-essential programs and utilities and never hook
>> it up to the net, foregoing the need for any anti-virus SW. It would be a
>> dedicated computer for doing nothing but sound.
>
> That's always good advice, but again, I reiterate - the majority of
> people who
> buy audio hardware and software for the purpose of recording do it to record
> themselves because they can, with very little money. Very few buy a computer
> exclusively for that purpose but use the computer that they use every
> day. For
> those people, the advice is to look for things that they can turn off
> and do it.
>
That does not sound like the OP's situation to me. The thought of doing it
live is too much of a risk for me to take without a dedicated computer. For
recording purposes I don't see why latency would be so much of a concern.
> Those are things that are under your control without much extra cost, space,
> or inconvenience.
>
> Does Vista and Win7 have MSCONFIG and SERVICES.MSC like WinXP does?
> If not, where do you send people to find services, processes, and
> programs that
> are running and can be turned off?
>
Yes they do.
> Any good "optimizing for audio" web sites for the newer operating
> systems yet? And
> do you have to worry about any of that with a Mac? Sorry for getting off
> the direct
> topic of latency, but it seems that the most effective answer to my
> question about reducing
> latincy is to make the computer able to run with a smaller buffer.
Speaking of latency, what did pipe organ players do to cope with seconds of
latency? We are talking maybe 10-30ms, apart for lockups.
Jay Ts
> Jay Ts wrote:
>
>>On my laptop, a bad WiFi driver was causing 22 ms. of latency. If I
>>recall correctly, it was once per minute.
>
> What do you actually mean by that?
Sorry, I was unclear. I was referring to the system latency that
the DPC Latency Checker measures. 22 ms was the length of the
delay in the WiFi device driver, and not from the audio
buffer. That is, every minute, the device driver would take over
the system for 22 ms., not allowing anything else to run. This
caused clicks and pops, because there was no way for the audio
subsystem to keep up in realtime. The audio buffer would
need to be set big enough to cover that 22 ms., and then some.
For purposes of comparison, after disabling the two offending
drivers, typical system latency is now about 150 microseconds,
maximum, which is no problem at all.
There is more information on how the DPC Latency Checker works
here:
http://www.thesycon.de/deu/latency_check.shtml
Look at the bottom, under "Background information: Why drop-outs occur".
This information answered some questions for me with regards to
the Windows device driver model. And the author of that page confirmed
my suspicion that not all device driver developers conform to
Microsoft's recommendations.
Basically, the DPC Latency Checker is telling how much time can pass
before applications have access to data from the device drivers.
It does this by measuring the maximum time that Deferred Procedure
Calls of the device drivers take to run. They have priority above
that of applications, so the applications won't run until the
DPCs are finished.
Jay Ts
> Speaking of latency, what did pipe organ players do to cope with seconds
> of latency? We are talking maybe 10-30ms, apart for lockups.
When playing an instrument, you naturally adjust for it, up to a point.
Also, pipe organ sound has a slow attack and very long decay
(if you include room reverb tail), so even 30 ms is short compared
to those. I've been running into this effect while playing flutes
and even pipe organ on my MIDI synth guitar setup. Aside from all
that, what people in the cathedral hear as pipe organ sound is
what they get, while the organist is playing it to sound right
to himself or herself. I think that's about the size of it.
A long time ago, I was reading (I think in Mix Magazine) about a
Rolling Stones tour setup. They had a 50 foot long catwalk extending
from the front of the stage, to allow Mick and Keith to be surrounded
by the audience.
At the end of the catwalk was a little round spot for Mick and Keith.
There were no monitors there.
Because of the 50+ ms. latency from the time it took sound to travel
from the PA speakers to the spot at the end of the catwalk, the engineers
wanted Keith to use an in-ear monitoring system, but he wouldn't have
anything to do with that. They were amazed that he was able to play
using the PA for monitoring, spot on.
Why did this work? Because Keith was listening for _synchronization_,
and allowed himself to automatically compensate for all latencies,
to make the sound coming out the PA speakers sound right. All
musicians automatically compensate for the latency of ear-to-brain-to-
mouth/fingers. And for a pianist, for example, the time it takes the
hammers to hit the strings, etc. If anyone can do that, another
few ms. of delay is a simple adaptation.
I like this example with the Rolling Stones, because I think it helps
put latency issues into perspective. For example, if a musician is
complaining to studio engineers about less than 10 ms. latency, is
he or she able to play in an acoustic band? I would ask. ;-)
And think of this. Sound travels through air about 1 foot per
millisecond, and light travels about 1 foot per nanosecond.
So sound is about a millionth as fast as light. Or around that
as compared to electrical signals. Pretty soon, the speakers-to-ear
latency of sound travel may be the dominant factor in many audio setups.
Yet another thing to consider when deciding to pay huge $$$ for a new
computer.
Laurence Payne
<sur...@stopassaultnow.net> wrote:
>Office has an office bar that takes up resources. So does indexing, upgrade
>schedulers, etc.
So turn it off. Though I doubt it's doing much more than duplicating
the icons for the various Office applications. Unless you have a very
old version of Office, I don't think there's a dedicated indexer any
more. Turn off the global Windows index service if you like. Updates
are handled by Microsoft Update, an extension to the general Windows
Update. But only if you choose to enable it.
Laurence Payne
wrote:
>Basically, the DPC Latency Checker is telling how much time can pass
>before applications have access to data from the device drivers.
>It does this by measuring the maximum time that Deferred Procedure
>Calls of the device drivers take to run. They have priority above
>that of applications, so the applications won't run until the
>DPCs are finished.
And very informative it can be when trouble-shooting a system.
Doesn't "latency" mean a lot of different things? :-) Almost as
bad as "virtual memory" - even Microsoft can't decide whether it
refers to the whole memory map or specifically to a swap file on disk.
Plenty of good arguments stem from THAT inconsistency :-)
Laurence Payne
wrote:
>When playing an instrument, you naturally adjust for it, up to a point.
>Also, pipe organ sound has a slow attack and very long decay
>(if you include room reverb tail), so even 30 ms is short compared
>to those. I've been running into this effect while playing flutes
>and even pipe organ on my MIDI synth guitar setup. Aside from all
>that, what people in the cathedral hear as pipe organ sound is
>what they get, while the organist is playing it to sound right
>to himself or herself. I think that's about the size of it.
I've played organs where there was considerable delay at the playing
position, both for acoustic reasons and because of the mechanism that
connected keyboard and pipes. You just keep your own tempo and try to
ignore what comes back. It engenders a somewhat fatalistic attitude
- if you hear a wrong note it's WAY too late to do anything about it!
Accompanying other instruments or solo singers is an interesting
experience. Again, you just keep going, hoping that they're
synchronizing with what THEY hear, and that the audience are getting
something coherent.
Mike Rivers
>> Very few buy a computer
>> exclusively for that purpose but use the computer that they use every
>> day. For
>> those people, the advice is to look for things that they can turn off
>> and do it.
> That does not sound like the OP's situation to me.
I'm the original poster, and no, it's not the situation for me. I have a
computer that
I occasionally let out of isolation to get updates and such, but it's a
refurbished Dell, (which means it's not badly gooked up with trial
versions and
useful-to-someone gadgets) and not custom built from supposedly
intelligently
selectec components.
> The thought of doing it
> live is too much of a risk for me to take without a dedicated computer. For
> recording purposes I don't see why latency would be so much of a concern.
I agree. I don't record live (or even regularly in the studio) using a
computer. It's
there so I can evaluate hardware. However, for live recording, latency
is indeed
not a concern. It can be 10 seconds if that's what it takes for a
reliable recording.
But I wasn't asking the question for my own use, I was asking to gather some
information for those who are using a computer as an instrument and signal
processor for live performance, and incidentally (because it's there) to
record the
performance.
Latency isn't important for the recording, but it's critical for live
performance if it
gets to be more than a few milliseconds. And the same things that
require buffering
for recording also require buffering for live throughput. You don't want
your synth
pads or guitar flanges to stutter while you're on the bandstand.
> Speaking of latency, what did pipe organ players do to cope with seconds of
> latency? We are talking maybe 10-30ms, apart for lockups.
They learn to play that way. It's part of becoming an organist. But "we"
have
computers so we shouldn't have to deal with old problems like the speed of
sound and sticky valves. ;)
Mike Rivers
> Sorry, I was unclear. I was referring to the system latency that
> the DPC Latency Checker measures. 22 ms was the length of the
> delay in the WiFi device driver, and not from the audio
> buffer. That is, every minute, the device driver would take over
> the system for 22 ms., not allowing anything else to run.
Wow! That's dreadful. This sounds like an operating system problem
to me, or maybe the driver not following the rules. I can't imagine any
sensible operating system letting something take over the computer
exclusively for that long. But then, this IS Windows.
> Basically, the DPC Latency Checker is telling how much time can pass
> before applications have access to data from the device drivers.
> It does this by measuring the maximum time that Deferred Procedure
> Calls of the device drivers take to run.
I've only played with DPC briefly. I ran it, saw that I had a nice low
number (for whatever reason, probably because I had already "optimized"
my computer based on suggestions that seemed reasonable) and
quit the program. If you read the instructions, can you point it at
specific drivers? Or do you just have to turn things off and see how the
total DPC time changes?
Mike Rivers
> I like this example with the Rolling Stones, because I think it helps
> put latency issues into perspective. For example, if a musician is
> complaining to studio engineers about less than 10 ms. latency, is
> he or she able to play in an acoustic band? I would ask. ;-)
That's a good question, and sadly, the answer is that we're dealing
with a significant portion of the "musician" population who don't play
in bands, and are working on playing all the parts themselves in their
bedroom, using a computer to simulate instruments that they've never
really learned to play. They don't have the experience that Mick and
Keith have, so they're surprised at the "play to the delay" skills that
need to be learned.
> Pretty soon, the speakers-to-ear
> latency of sound travel may be the dominant factor in many audio setups.
This is fixed with headphones.
Jay Ts
> Jay Ts wrote:
>
>> Sorry, I was unclear. I was referring to the system latency that the
>> DPC Latency Checker measures. 22 ms was the length of the delay in the
>> WiFi device driver, and not from the audio buffer. That is, every
>> minute, the device driver would take over the system for 22 ms., not
>> allowing anything else to run.
>
> Wow! That's dreadful.
Yes, now you get it.
> This sounds like an operating system problem to
> me, or maybe the driver not following the rules. I can't imagine any
> sensible operating system letting something take over the computer
> exclusively for that long. But then, this IS Windows.
It can happen with any operating system. The design must allow
device drivers to run uninterruptibly, because they access hardware,
and hardware usually does not wait around nicely for the OS to feel like
dealing with it.
What surprised me was learning that the problem was caused in the DPC
(Deferred Procedure Call) part of the device driver. This apparently
is similar to the Linux model, where the immediate response to the
hardware is to allow the device driver to run a very quick operation
during the initial "do this RIGHT NOW" exception processing stage.
At this point, I think it's not too much of a stretch to say that
the device driver "becomes" the operating system for a brief period.
That is, just to do one thing, and then pass control back to the
kernel. The idea is to have fast response to the needs of the hardware,
and schedule most of the work for later, to allow other hardware to
get attention in the same way.
The next stage is then the Deferred Procedure Call (DPC), where that work
is performed. What that webpage was saying is that in Windows, all
of the DPCs are done at a higher priority than applications, so all
of the work of all of the DPCs has to be done before any application
("thread") is allowed to run. It is therefore also very important here
that the DPC does not take very much time to run.
If the device driver developer takes a shortcut, and just lets
the DPC do whatever work it needs to to finish the job, regardless
of the time taken, there can be a problem. In the case of my WiFi
driver, a BIG problem.
In the worst conceivable case, imagine what happens if the DPC
fails to finish before another hardware interrupt of the same
type occurs, and this keeps happening. In this case, no thread
will ever run, and a system lockup occurs. "Thread" includes
parts of the operating system, such as the user interface. The
system would still be responding to hardware interrupts, but
you would need to press the reset button or do a power cycle to
clear the problem.
If I were really good, I would search through the Microsoft Knowledge
Base until I found "definitive documenatation" for all this. But having
spent too much time in the past looking for "definitive documentation"
at the Microsoft site, and ending up really disgusted, I'd rather
not bother today. So I'm sorry if I'm a little off about this stuff.
> I've only played with DPC briefly. I ran it, saw that I had a nice low
> number (for whatever reason, probably because I had already "optimized"
> my computer based on suggestions that seemed reasonable) and quit the
> program. If you read the instructions, can you point it at specific
> drivers?
Oh, I wish it were that simple! What happens is that you run it,
and you see huge red bars appearing at various intervals, and you
can see the amount of latency in microseconds. If you are
lucky, the bars will be at predictable times (regular intervals).
Then, you go into Device Manager, and for each device, try
disabling it to see if the red bars go away. You have to
try each device until you find the right one. If the red
bars appear infrequently, it can take a long time.
Then, after you get the worst offender, you can see if there
are any smaller ones you'd like to have go away. Next, next, next...
The idea is to get it so that the bars are down in the green area.
Probably there are just one or two offenders. And there
are more likely candidates, such as the WiFi adapter and battery
monitor. So if you make good guesses, it may not be so bad.
It takes time and patience.
Mike Rivers
> . . . the immediate response to the
> hardware is to allow the device driver to run a very quick operation
> during the initial "do this RIGHT NOW" exception processing stage.
> . . . just to do one thing, and then pass control back to the
> kernel. The idea is to have fast response to the needs of the hardware,
> and schedule most of the work for later, to allow other hardware to
> get attention in the same way.
> The next stage is then the Deferred Procedure Call (DPC), where that work
> is performed.
That clarifies my understanding of how a (proper) driver works - get the
data,
return control to the operating system, tell the OS what it needs
to do with the data it got, and then wait for the OS to give it time to
do that
procedure.
> What that webpage was saying is that in Windows, all
> of the DPCs are done at a higher priority than applications, so all
> of the work of all of the DPCs has to be done before any application
> ("thread") is allowed to run. It is therefore also very important here
> that the DPC does not take very much time to run.
Ah, so it's effectively hogging time from the application ASAP rather
than sharing time with the application. I guess it's important to a
programmer
to separate the data acquisition and the processing (procedure)
operation, but
to someone looking at the application activity, it all looks like one
big stall.
> If the device driver developer takes a shortcut, and just lets
> the DPC do whatever work it needs to to finish the job, regardless
> of the time taken, there can be a problem. In the case of my WiFi
> driver, a BIG problem.
I must have a pretty good one. I ran DPC on my laptop with the WiFi
disabled, then enabled it and got one big spike on the DPC graph,
and then it settled down. There was a little more activity than without
the WiFi enabled but it was still below the yellow line. I didn't see any
regularly spaced spikes like the illustration in the DPC documentation,
even when I moved a file across the network from another computer,
or connected to a web page.
> In the worst conceivable case, imagine what happens if the DPC
> fails to finish before another hardware interrupt of the same
> type occurs, and this keeps happening. In this case, no thread
> will ever run, and a system lockup occurs.
Hopefully that doesn't occur unless the system is really badly
burdened down with hardware interrupts.
lowg...@ao1.com
I don't believe this at all.
The belief seems to be that data is intentionally pushed into the end of a
fixed-length buffer and nothing happens until the buffer is filled, while
the program feeding the buffer and the program needing the data do what
they must in order to keep the buffer full.
But this is the description of a "bucket brigade" (I think it's called)
used for intentional delay, and is not relevent to this thread.
The buffers used in audio streaming operations are used to insure that data
is always available for the program that does the dequeuing (like a clocked
sound card). Buffers are needed because the program supplying the data may
fall behind as a result of being pre-empted by some unrelated process.
I've written very-high-speed drivers which used buffers. There was a
pointer to the virtual "head" of the buffer from which the next byte was to
be fetched. There was a pointer to the virtual "tail" of the buffer where
the next byte could be stored. Dequeueing a byte was grabbing the byte at
the head and decrementing the pointer (and checking for a wrap). Adding a
byte to the buffer was the simple reverse of that. There was no "shuffling"
involved at all, and the buffer could have been megabytes long with no
impact on the result.
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Windows installs with a ton of baggage-- active processes that Microsoft
believes are "good for you" or (just as likely) good for them. There is no
reliable documentation anywhere of what these processes do. MS's
description of what they do and which are "required" is often untrue. There
are no websites to explain them (BlackViper.com is a start but some is
wrong and much is missing.)
I spent over a month stripping down my XP system and now it now runs very
hot. There is NO unexplained disk access or internet activity.
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Anyone who expects Microsoft to provide the best anti-malware protection in
the consumer's best interest lives in dreamland.
Laurence Payne
>Half the posts here claim that buffers cause latency.
>
>I don't believe this at all.
>
>The belief seems to be that data is intentionally pushed into the end of a
>fixed-length buffer and nothing happens until the buffer is filled, while
>the program feeding the buffer and the program needing the data do what
>they must in order to keep the buffer full.
If what you're streaming is media data, a fixed delay can be
compensated for. But an ever-varying delay would cause chaos.
>Anyone who expects Microsoft to provide the best anti-malware protection in
>the consumer's best interest lives in dreamland.
That's just an attitude. Have you anything to tell us about Microsoft
Security Essentials? There seems to have been very little discussion
of it.
lowg...@ao1.com
>>the consumer's best interest lives in dreamland.
>That's just an attitude. Have you anything to tell us about Microsoft
>Security Essentials? There seems to have been very little discussion
>of it.
I wouldn't sign up for this MS product any more than I'd buy chicken
protection from The Friendly Fox Family software company.
You want to dismiss this as an "attitude"? No problem-- I'm ok.
Don Pearce
You dismiss to readily. It is a very high quality product, with a very
minimal footprint and just about the highest interception rate in the
industry. The price is right too.
d
Mark
> Half the posts here claim that buffers cause latency.
>
> I don't believe this at all.
>
> The belief seems to be that data is intentionally pushed into the end of a
> fixed-length buffer and nothing happens until the buffer is filled, while
> the program feeding the buffer and the program needing the data do what
> they must in order to keep the buffer full.
>
>
No, typically a buffer is kept near 1/2 full so that either the source
or the sink can speed up or slow down short term....long term they
must be kept at the same average rate or the buffer will eventually
empty or overflow...
The water bucket analogy is very helpful here.
Mark
Don Pearce
wrote:
I've never known a buffer work that way. In aviation there is a
saying: There are three useless things - fuel in the bowser, altitude
above you and runway behind you. You can add empty buffer space to
that list for electronics.
You keep a buffer as full as you can, and request a new piece of data
as soon as there is space. That way you gain maximum protection from
temporary data delay.
d
Mike Rivers
> Half the posts here claim that buffers cause latency.
> I don't believe this at all.
The don't cause it, they contribute to it.
> The buffers used in audio streaming operations are used to insure that data
> is always available for the program that does the dequeuing (like a clocked
> sound card). Buffers are needed because the program supplying the data may
> fall behind as a result of being pre-empted by some unrelated process.
Right. And the way that's done is to be sure that the buffer is
reasonably full.
But if things don't come out in the order that they went it, you have a
mess to
de-queue.
> I've written very-high-speed drivers which used buffers. There was a
> pointer to the virtual "head" of the buffer from which the next byte was to
> be fetched. There was a pointer to the virtual "tail" of the buffer where
> the next byte could be stored. Dequeueing a byte was grabbing the byte at
> the head and decrementing the pointer (and checking for a wrap). Adding a
> byte to the buffer was the simple reverse of that. There was no "shuffling"
> involved at all, and the buffer could have been megabytes long with no
> impact on the result.
So, have you written drivers for any of the audio interfaces that people
use
for their recording studios? If so, which one(s). It would be
interesting to
check them out.
Laurence Payne
Ok, you're out of the conversation. Has anyone else seen informed
comments or a comparative review?
Laurence Payne
>I've never known a buffer work that way. In aviation there is a
>saying: There are three useless things - fuel in the bowser, altitude
>above you and runway behind you. You can add empty buffer space to
>that list for electronics.
>
>You keep a buffer as full as you can, and request a new piece of data
>as soon as there is space. That way you gain maximum protection from
>temporary data delay.
Sure. And under circumstances where you could have got along without
a buffer, it stays full. When the things that prompted you to HAVE a
buffer occur, it empties a bit. And it seems sensible to go easy on
the request to re-fill it RIGHT NOW, 'cos by definition it's the wrong
time to be asking!
Don Pearce
Of course it isn't. Why ever would you want to delay that request?
What, in other words, is the advantage of a less-than-full buffer? If
your buffer is full, you may have, say, a half second of data on tap,
ready to cover any stoppage of incoming data. If that same buffer is
only half full, you can only handle a quarter of a second. Why would
you want to put yourself in that position?
d
Laurence Payne
>>Sure. And under circumstances where you could have got along without
>>a buffer, it stays full. When the things that prompted you to HAVE a
>>buffer occur, it empties a bit. And it seems sensible to go easy on
>>the request to re-fill it RIGHT NOW, 'cos by definition it's the wrong
>>time to be asking!
>
>Of course it isn't. Why ever would you want to delay that request?
>What, in other words, is the advantage of a less-than-full buffer? If
>your buffer is full, you may have, say, a half second of data on tap,
>ready to cover any stoppage of incoming data. If that same buffer is
>only half full, you can only handle a quarter of a second. Why would
>you want to put yourself in that position?
OK, so ask straight away and take your chance. The point being, if
your buffer is always almost full, you've chosen too big a buffer
size. You could have chosen smaller and achieved lower latency.
Don Pearce
No, I didn't say your buffer is always full. I said you keep it topped
up whenever data is available. It could be almost empty at some point
if there is a blockage in data flow. If that happens, but you have
failed to top it off while the data was available, it will empty and
you will look silly.
You design the size of the buffer based on the maximum length of time
data input might be interrupted.
And what purpose is served by an upper expanse of buffer that you
never fill up anyway. What exactly does it give you? It can't be spare
in case you need it - because in that circumstance it would be empty
and useless. Or do you perhaps anticipate that a gap in data flow is
going to happen any moment now and fill it up just in time?
d
hank alrich
> Laurence Payne wrote:
>
> > What's this all about? Are you hoping to get an article out of the
> > subject?
>
> Yes. I get tired of seeing the the question "Does it have low latency?"
> asked about nearly any new sound card or audio interface that someone
> hears about and have to ask "what latency are you talking about?" It
> seems that most people don't know anything about it other than that low
> is good.
I just got here. What are y'all talking about?
--
ha
they'll never fall for this one
Les Cargill
> Half the posts here claim that buffers cause latency.
>
> I don't believe this at all.
>
> The belief seems to be that data is intentionally pushed into the end of a
> fixed-length buffer and nothing happens until the buffer is filled, while
> the program feeding the buffer and the program needing the data do what
> they must in order to keep the buffer full.
>
So you're of the George Carlin "the glass is twice as big
as it needs to be" persuasion? The latency for an audio
device driver is exactly equal to the number of samples
in one exchange with the soundcard times 1/Fs. Sadly,
many soundcards/drivers don't always deliver the same
number of samples - I have no idea why this is. But if
you open the driver on this machine directly and
nonblocking, you'll get two different lengths of "fread()".
> But this is the description of a "bucket brigade" (I think it's called)
> used for intentional delay, and is not relevent to this thread.
>
You might look at how jitter buffers in VoIP work. They're relevant
and a valid model for relieving a soundcard of sample
data. They're too *smart* for that, but the delay effects
are exactly the same.
<snip>
--
Les Cargill
Les Cargill
Uh.... nothing's slowing down or speeding up here. Fs is a constant...
--
Les Cargill
Les Cargill
> On Wed, 02 Dec 2009 00:43:20 +0000, Laurence Payne
>
> And what purpose is served by an upper expanse of buffer that you
> never fill up anyway. What exactly does it give you? It can't be spare
> in case you need it - because in that circumstance it would be empty
> and useless. Or do you perhaps anticipate that a gap in data flow is
> going to happen any moment now and fill it up just in time?
>
> d
"Some people see the glass half full. Others see it half empty.
I see a glass that's twice as big as it needs to be."
� George Carlin
--
Les Cargill
Mike Rivers
> I just got here. What are y'all talking about?
People who don't know what "latency" is, but only know that they want it
to be low.
hank alrich
Oh, I see. Latexy. It's slick, and low is good.
--
ha
shut up and play your guitar
http://www.armadillomusicproductions.com/CarryMeHome.htm
http://hankalrich.com/
Les Cargill
Somethin' called "latency". I think it has to do with whether or not
yer computer needs to be in a closet.
Not that there's anything wrong with that.
--
Les Cargill