3 title: The Right Computer System for Digital Audio
\r
4 menu_title: The Right Computer System
\r
8 It would be nice to think that you could just go and buy any computer,
\r
9 install a bit of software on it and start using it to record and create
\r
10 music. This idea isn't wrong, but there some important details that it
\r
14 Any computer that you can buy today (since somewhere around the end of
\r
15 2012) is capable of recording and processing a lot of audio data. It
\r
16 will come with a builtin audio interface that can accept inputs from
\r
17 microphones or electrical instruments. It will have a disk with a huge
\r
18 amount of space for storing audio files.
\r
21 When you are recording, editing and mixing music, you generally want to
\r
22 work with very little <dfn>latency</dfn> between the time that
\r
23 a sound is generated and when you can hear it. When the audio signal
\r
24 flows through a computer, that means that the computer has to be able to
\r
25 receive the signal, process it and send it back out again as fast as
\r
27 And that is where it becomes very important <em>what</em> computer system
\r
28 you have, because it is <strong>absolutely not</strong> the case that any
\r
29 computer can do this job well.
\r
32 Routing audio through a computer will always cause some delay, but if it
\r
33 is small, you will generally never notice it. There are also ways to work
\r
34 in which the delay does not matter at all (for example, not sending the
\r
35 output from the computer to speakers).
\r
38 The latency that you want for working with digital audio is typically in
\r
39 the 1–5 ms range. For comparison, if you are sitting 1 m
\r
40 (3 ft) from your speakers, the time the sound takes to reach your
\r
41 ears is about 3 ms. Any modern computer can limit the delay to
\r
42 100 ms. Most can keep it under 50 ms. Many will be able to get
\r
43 down to 10 ms without too much effort. If you try to reduce the delay
\r
44 on a computer that cannot meet your goal, you will get clicks and
\r
45 glitches in the audio, which is clearly extremely undesirable.
\r
48 <h2>Hardware-related Considerations</h2>
\r
49 <dl class="wide-table">
\r
50 <dt>Video interface</dt>
\r
51 <dd>Poorly engineered video interfaces (and/or their device drivers) can
\r
52 "steal" computer resources for a long time, preventing the audio interface
\r
53 from keeping up with the flow of data</dd>
\r
54 <dt>Wireless interface</dt>
\r
55 <dd>Poorly engineered wireless networking interfaces (and/or their device
\r
56 drivers) can also block the audio interface from keeping up with the flow
\r
58 <dt><abbr title="Universal Serial Bus">USB</abbr> ports</dt>
\r
59 <dd>If you are using an audio interface connected via USB, and sometimes
\r
60 even if you are not, the precise configuration of your system's USB ports
\r
61 can make a big difference. There are many cases where plugging the
\r
62 interface into one port will work, but using different USB port results
\r
63 in much worse performance. This has been seen even on Apple systems.
\r
65 <dt>Internal USB Hubs</dt>
\r
66 <dd>Ideally, you'd like your USB ports to all connect directly to the
\r
67 main bus inside the computer. Some laptops (and possibly some
\r
68 desktop systems) come wired with an internal USB hub between the
\r
69 ports and the system bus, which can then cause problems for various
\r
70 kinds of external USB devices, including some models of audio
\r
71 interfaces. It is very difficult to discover whether this is true or
\r
72 not, without simplying trying it out.</dd>
\r
73 <dt><abbr title="Central Processing Unit">CPU</abbr> speed control</dt>
\r
74 <dd>Handling audio with low latency requires that your processor keeps
\r
75 running at its highest speed at all times. Many portable systems try to
\r
76 regulate processor speed in order to save power — for low latency
\r
77 audio, you want this totally disabled, either in the BIOS or at the OS
\r
79 <dt>Excessive Interrupt Sharing</dt>
\r
80 <dd>If your audio interface is forced by your computer to share an
\r
81 interrupt line (basically a way to tell the CPU that something needs
\r
82 its attention) with too many, or the wrong, other devices, this can also
\r
83 prevent the audio interface from keeping up with the flow of data. In
\r
84 laptops it is generally impossible to do anything about this. In many
\r
85 desktop systems, it is possible at the BIOS level to reassign interrupts
\r
86 to work around the problem.</dd>
\r
87 <dt><abbr title="System Management Interrupt">SMI</abbr>s</dt>
\r
88 <dd>SMIs are interrupts sent by the motherboard to tell the computer
\r
89 about the state of various hardware. They cannot safely be disabled,
\r
90 but they can also take a relatively long time to process. It is better
\r
91 to have a motherboard which never sends SMIs at all — this is
\r
92 also a requirement for realtime stock trading systems, which have
\r
93 similar issues with latency.</dd>
\r
94 <dt>Hyperthreading</dt>
\r
95 <dd>This technology is becoming less common as actual multi-core CPUs
\r
96 become the norm, but it still exists and is generally not good for
\r
97 realtime performance. Sometimes you can disable this in the BIOS,
\r
98 sometimes you cannot. A processor that uses hyperthreading will be
\r
99 less stable in very low latency situations than one without.</dd>
\r
100 <dt>Excessive vibration</dt>
\r
101 <dd>This doesn't affect the flow of data to/from the audio interface,
\r
102 but it can cause the flow of data to/from your disk storage to become
\r
103 <em>much</em> slower. If you are going to use a computer in an
\r
104 environment with loud live sound (specifically, high bass volume),
\r
105 make sure to place it so that the disk is not subject to noticeable
\r
106 vibration. The vibrations will physically displace the head-write
\r
107 heads of disk, and the resulting errors will force a retry of the
\r
108 reading from the disk. Retrying over and over massively reduces the
\r
109 rate at which data can be read from the disk. Avoid this.</dd>
\r
projects / ardour-manual / blob