Consoles 989USB microphones, which only work in that context.
The PC to which they are connected can recognize such
simple interconnections as just an external Sound Card,
and has generic drivers built in to cope. Zero-effort
connectivity. Better performance and more advanced
control and features can be achieved with special
drivers installed in the PC, but the instant connectivity
thing is hard to beat.
One rightly has to be circumspect about jitter perfor-
mance on a transport mechanism that certainly was
never characterized for digital audio streaming with
very stringent clock recovery requirements; in the case
of the small DAW setup described, since A/D and D/A
are in the same box, and assuming the clocking is done
conscientiously within, the overall performance is
limited by that, any vagaries of the link, its latency, or
computer timing being irrelevant as long as the clocks
remain synchronous with the data. Such are the dangers
of any transport scheme where the clock is solely
implicit to the data, with no external reference.
Of far more concern, however, is the computer’s
operating system’s handling of audio, which can make a
land of horrors transcending any worries about link
jitter; this is typically addressed by the loading of
unit-specific drivers (ASIO in this case) into the
computer, which blow right by the operating system’s
clunky hardware abstraction scheme, and instituting
delay buffers capable of absorbing most temporal irregu-
larities. Nevertheless, a USB (and perhaps more so
FireWire) link’s performance is often dropout-limited by
the host PC’s handling of (deferred procedure calls), the
stacking up of interrupts and time-related routine calls
that take longer to address and clear than the link’s
buffers can sustain. Sometimes a lot of effort has to be
put into disabling features/programs/peripherals (like
wireless networking in particular), updating or finding
the right/better drivers, optimizing this and that,
installing replacement hardware, and general hair
tearing, just to get a PC to adequately pass/process
meaningful amounts of audio. The PC really is not a
shining beacon of a streaming-audio-friendly environ-
ment!
25.25.3 Digital Audio Networking
25.25.3.1 CAT-5/RJ-45 interconnectivity types
The following communication schemes all typically use
the widely available (even from the local stationery
store) networking style cabling, exemplified by CAT-5
or CAT-6 cable terminated in the little plastic RJ-45
phone like connectors, and indeed often share the same
terminating MAC and PHY electronics. What actually
goes through them can differ wildly though. As will
become plain, this enabling technology has also
expanded the notions of what can be done in the context
of moving large amounts of audio around, blurring the
distinctions of transport, mixing, and processing.25.25.3.2 TCP/IP—Audio over EthernetEthernet, using its handmaiden TCP/IP platform, is
highly popular—ubiquitous—and there is a large base
of skill in operating and maintaining networks based on
it. This has lent impetus to trying to use it for things for
which it wasn’t really intended and is not particularly
apt, such as moving professional audio. Immense effort
and marketing has gone into making it work adequately.
Probably best placed elsewhere.
Any Internet user knows how facile it is to move
audio around, either in chunks as files or drip fed as
streaming, either on a local network or the internet
itself. A seemingly sensible follow-on would be to
wonder if the self-evidently already existent method-
ology could be used for moving large quantities of
audio around in a digital audio network.
Well, the short answer is “Yes.” Given the existence
of Ethernet connectivity and a good IP stack (network
operating firmware) in each of the required connected
units, a significant number of uncompressed audio
channels can be moved around successfully by such a
network. However, the long answer begins. Aspects of
its performance at best are eclipsed by alternative
methods. The only real advantage is the previously
mentioned wealth of user familiarity with, and labor
skilled in, TCP/IP networking. There are significant
drawbacks.
In the Internet example, the audio is almost always
compressed by MP3, WMA, AAC, Ogg-Vorbis, or
whatever format to radically reduce file size or to fit
within a required streaming rate. Except for a few argu-
able examples such as news, remote, or commercial
distribution for radio broadcast, compressed audio has
no place in professional audio. So suddenly the neces-
sity of uncompressed audio payload can be ten times or
beyond the size of domestic audio. Network congestion
effects loom that much closer, that much sooner.
TCP/IP is a packetized system and incurs at best a
minimum packet assembly/disassembly time at the ends
in addition to the relatively quick transmission times.
The packets are ordinarily comparatively small—in a
streaming sense—multiplying the processing/depro-