Eventide H8000FW, Operating Manual

Page: 169 / 206

163
here is to fill buckets (the buffers) with coal from the pile, and pass them to a colleague
who then empties them into a chute leading to the outside world. The chute must be kept
partially full but not allowed to overflow. The chute may be thought of as the feed to an
external digital to analog converter feeding a speaker, while the passing of the buckets
represents the FireWire connection.
So, if the chute becomes empty the speaker will pop or click, while if it overflows things
may get in the wrong order. It also takes time for any given piece of coal to get from the
pile to the chute, as the buckets have to be filled and emptied before this can happen. This
time is the latency mentioned above.
It will be apparent that the size of the buckets directly affects the latency, as smaller
buckets can be filled and emptied more quickly. But, to avoid the chute becoming empty
(bad!), they will have to be passed more quickly, which may be tiring. So, there is probably
an optimum size for these buckets, to provide a good compromise between the latency on
one side, and the energy requirement (computer power) needed to pass them.
Enough of coal for now. The latency is usually almost directly proportional to the buffer
size, but the use of small buffers requires more computer power. The default setting is
usually a good compromise, but if low latency is important and you have a fast computer
it may pay to reduce it.
Some simple math for those so inclined: if you are running at 48kHz, a 1024 sample
buffer will introduce a latency in the order of 1024/48000 seconds, or 21mS
(milliseconds). So, to send and return to a FireWire device will take 42mS, which is
noticeable. Those systems that offer
delay compensation can resolve the problem painlessly,
but otherwise the use of smaller buffers is worth considering.
Synchronizing connected audio devices
For audio purposes, a computer can be thought of as a device that shuffles processed data
between its disk drives, memory and peripherals. As such, it neither has nor needs the
concept of a sample rate (except for calculating delays or filters and such-like). This
concept only becomes necessary when it is necessary to output audio to or from the
outside world, in which case it is set by the hardware conversion devices.
Things become more complex when you have more than one device that cares about the
sample rate because if a device gets data at the wrong sample rate it will have to drop
samples or insert extra samples to keep up. This will cause clicks or distortion, depending
on its severity. To avoid this, we allow one device, known henceforth as the
clock master , to
define the sample rate and any other devices have to follow its lead.