From: "Richard B. Ingraham" <rbingraham@...>
>> From: AudioBox@yahoogroups.com
>
>> Increasing the latency does not reduce CPU load materially.
>> Arguably it increases the CPU load if it is done wrong.
>> Reducing the latency to less than three or four packets does
>> not allow for times the machine decides to do its own thing.
>> But more than 4 packets starts to get silly and increases the
>> computing challenge "slightly". The real problem is pushing
>> the samples in from the source, through filters, delays,
>> level shifts, matrix connection calculations, and on out the output.
>>
>
> The this is counter to all of my experiences with DAWs then. I don't
> know how all this buffer stuff works well enough to really give
> examples, but all I know is if my CPU is running out of gas with too
> many plug-ins or software synths, etc.... on any of my DAW applications,
> (i.e. I'm getting clicks, pops, drop outs, etc...) I can go into the
> ASIO control panel, and turn up the buffers (ie. which adds latency) and
> then get more out of the same CPU. I can get a lot more work out of the
> same CPU with 1024 buffers than with 64, etc, etc....
Likely that means there are transient intervals during which the
machine gets overloaded with what you're doing, perhaps during disk
accesses. The CPU is probably doing more work total with the
additional buffers; but, the work peaks are effectively 'smeared out
over time' by the buffering.
>> (And live is less work than clip because there is no file
>> system overhead involved.) {^_^}
>
> But live audio does have to pass through any buffers twice correct?
> Once on the way in, and again on the way out?
So does the information from the disk. Actually if there is any
increase or decrease in CPU load for more or fewer buffers it would
come from going through special code for powers of 2 cases, which
can slightly reduce CPU load, small numbers of instructions. The
FIFO really should take very little time to process. If the size of
the buffers is made larger (not the number) there will be a slight
reduction in CPU load. If it's more than a fraction of a percent
the FIFO code could probably be optimized better. If the number of
buffers is increased or decreased all that does is provide more
"slop" for times the operating system insists it has to do something
ridiculous like run a Norton scan on a file you've just opened or
some other internal bookkeeping for spoo only knows what strange
reason. So fetching and placing packets of data into FIFO buffers
is the place extra time appears and disappears. And the OS is a
"thing" that can decide it knows better than you do what you want
done at a given time and by foo does it regardless of priority
settings.
Everything else in the audio path takes a constant time regardless
of the shape of the buffers.
{^_^}