990 Chapter 25
cessing overhead and bandwidth wasted in sending
packet headers. This can be tweaked, however.
This all incurs latency (i.e., a delay between input
and output) that may or may not be acceptable. Live
applications—say, broadcast or sound reinforcement—
might well have issues, particularly if many links’ laten-
cies become cumulative. These are relatively minor
latencies, though, compared to what’s to come in a real
environment. Oh, yes. It gets worse....
Congestion is paradoxically key to TCP/IP’s main
limitation for audio, considering it was designed to—and
does—handle congestion superbly for its intended use.
In the absence of any other network traffic that may
contend with a primary audio stream, the packetized
audio will likely arrive unmolested and in order, and a
fairly high density (lots of audio) may be passed from a
point A to a point B. In short, in a point-to-point dedi-
cated link, audio via TCP/IP can work reasonably well.
Unfortunately, that’s not what the network concept
promises: multiple independent streams from multiple
sources and with multiple destinations sharing the same
wire infrastructure. As soon as other traffic hits the
network—say, another audio stream from point C to
point D—try as the carrier-detect collision avoidance
mechanisms inherent to Ethernet might, packets from
one stream will unavoidably tread on those from the
other. One of TCP/IP’s great strengths is that it recog-
nizes such events and deals with them handsomely;
each stream gets the opportunity to resend its broken or
unacknowledged (i.e., lost) packets, and the receive
stack knows to reassemble the stream in the correct
order from the now possibly out-of-order and certainly
delayed packets. So what’s wrong with that?
25.25.3.2.1 Buffering Latency
The network has lost any tenuous claim to determinism
—predictability—it may have shown, since collisions
and recovery therefrom are unpredictable both in
frequency and recovery time. Determinism is, in short,
knowing exactly and consistently when recovered audio
is ready for use—absolutely essential for streaming-
type or real-time audio or dropouts occur. A pure,
isolated, low-density point-to-point TCP/IP link can be
close to deterministic and with a relatively short latency,
predictable from the above-mentioned packetization,
framing, and transmission times. Even so, it’s only
close—other traffic still exists on the link, in the form of
ACK (acknowledge) replies for each sent packet: Yes,
collisions can occur between the real data and its own
ACKs! Real-world, where multiple paths on the
network are in use, significant collision-recovery times
get thrown into the mix and this now unknown added
time becoming even more so and approximately
geometrically longer as the amount of traffic increases.
There is also the very strong likelihood, nay—certainty,
that packets that have been stepped on and repeated will
arrive out of sequence, the repeats only getting through
sometimes many frames after several in-sequence
packets have progressed.
The workaround—trading a fixed, known, longer
latency for a shorter but unusably unpredictable one
—is by instituting a fifo buffer (first in, first out) at each
receive point. In order to allow time for packets to be
eventually received and juggled back into order, this
fixed deliberate buffer latency has to be incurred; the
more traffic, the more latency is required, and on a busy
network this can be in the tens or hundreds of millisec-
onds to encompass worst-case congestion effects.
Although acceptable in some circumstances this is diffi-
cult to swallow for many audio applications—particu-
larly those where there is a requirement for humans to
listen to themselves live through such a system. Conse-
quently, lowish-latency and pseudo-deterministic audio
links are usually recommended to be placed on discrete
one-to-one links with little risk of contention. Which
really rather begs the rationale behind using TCP/IP,
and the promise of “networking” upon it. Oh, well. All
of these ills are exacerbated if any other traffic is
permitted on the same network—which finishes off the
naive notion of running significant amounts of audio on
an existing office network. Worse yet is expecting
sensible behavior if incoming or outgoing real-time
audio is expected through the Internet—build-out laten-
cies may have to be far, far longer to absorb the hairi-
ness of the unknown out there! Again, this may be
acceptable in some circumstances—after all, if one is
using the Internet, the likelihood is that the audio is
going a long way away, where no frame of reference in
time exists to its source.
One saving grace of the general move to gigahertz
Ethernet (as opposed to the more commonplace
100 MHz variety) is that everything happens much
quicker, and that for normal practicable amounts of
traffic the collision rate and recovery times go right
down and so the build-out buffering latency can be radi-
cally reduced; TCP/IP as the basis for an audio network
reaches a lot closer to the promise, as opposed to the
highly marginal on-the-edge behavior of any meaningful
size system at 100 MHz. The advantage is not so much
that ten times the traffic could theoretically be handled,
but that a similar amount of traffic can be handled well;
latencies in the single-digit milliseconds are readily
achievable, which, if not too many passes through the