By DAN GOLDSTEIN
THERE’S A TECH INDUSTRY JOKE THAT GOES: A CAR IS
GOING DOWNHILL WHEN SUDDENLY THE BRAKES FAIL. The driver eventually manages to stop the car
One passenger, a clergyman, says a thankful prayer. The next, a mechanic,
several things that might be wrong with the brakes. The third, a computer
programmer, says, “Let’s push it back up the hill and see if that happens
| DAW: What people think I do.
If you’ve spent any serious time with a DAW, this is either very funny
or very not,
depending on how many work hours your last crash cost you. Mac or PC, laptop or
desktop, sooner or later your software will crash. Why is it that your DAW will
perfectly for hours or days on end, and then suddenly crash for no apparent
| What I actually do.
Timing Bugs. During playback or recording,
your computer is reading audio files, mixing
tracks, processing effects, communicating with
your audio interface, and painting the meters
onscreen—all involving millions of math calculations per second. In the
background, your computer may be checking for email, searching for
software updates, and so on—though you should
disable any non-essential, non-audio tasks when
working. Sometimes software expects things to
happen in a certain order, and 99% of the time,
that’s exactly what happens. But if the order
changes, that may be enough to cause a crash.
These “intermittent” bugs are the most difficult
ones for programmers to find, because almost
every attempt to recreate the problem fails.
At Acoustica, we recently encountered a
virtual instrument that would crash in Mixcraft when the instrument’s edit
window was dis-
played. The developer had tested their product
in other DAWs, which sent instructions in a
slightly different order than Mixcraft does.
Everything Mixcraft was doing was “legal,” but
this plug-in had been written to expect events
to occur in a certain order (itself a reasonable
assumption), and when that order changed, the
result was a crash.
Driver Bugs. Drivers are little pieces of soft-
ware that tell your OS how to communicate with
a piece of hardware. Imagine dozens of different
manufacturers all over the world, writing drivers that are almost, but not
with each other. Minor variations in how
drivers work can cause huge headaches for
Case in point: Your DAW can ask audio
hardware to tell it exactly how many samples
have been played back by the audio interface,
so that you can have sample-accurate editing
and sync. But what happens if we ask your
audio interface how many samples have been
played, while at that precise instant, another
processor in your computer is asking your
audio interface to play some more samples?
With almost all audio interface drivers, that
conflict didn’t cause a problem, but with one
particular driver for one interface, our software
Programmers are human. Sometimes, programmers write erroneous code.
Over the years,
engineers have developed tools and methods to
squash bugs before customers trip over them,
and good programmers go to great lengths to write solid, bug-free code, but
occur frighteningly often.
Many such mistakes happen when a programmer hasn’t taken into
something that a user might do with the software.
No matter how many programmers, quality assurance engineers, beta testers, and
use a product, it’s practically impossible to envision every combination of
keystrokes and mouse
clicks someone might try. What happens in your
DAW if you hit the Delete key on a sound clip
while you’re dragging it to another track? That
may remove the clip from the project while it’s
being moved, and this action may confuse the
software if your DAW hasn’t been written to
cope properly. This exact operation used to crash
Mixcraft before we discovered the fl aw.
So, what can we do? Should we hide in the
closet with a candle and a four-track tape recorder and swear off digital
In truth, there are several things that you can
do to reduce your chances of hitting an inspiration-destroying software crash
in the middle
of a session. Here are a few steps that you can
take that may help your software run more
1. Get the latest DAW updates. Yes, we know
it’s annoying when your DAW keeps telling you
to download an update. The truth is, programmers are constantly working to fix
bugs in our software. When we publish an
update, it’s because we want to keep you from
running into problems that we’ve already found
2. Get the latest drivers for your audio interface. It’s easy to blame
your DAW when it
crashes, but there are numerous outside forces
that can take down your DAW, including buggy
drivers. Getting the latest drivers for your audio hardware (and also your MIDI
might eliminate a crash that really has nothing
to do with your DAW. You’d be surprised how
often this simple step fixes problems.
3. Get the latest operating system updates.
It’s not just about your DAW and drivers. Your
OS facilitates communication between your
software and hard drives, your audio devices,
your hardware dongles, the Internet, even your
RAM. Operating system updates can make your
entire computer run more smoothly, and can fix
tiny incompatibilities that can affect your DAW’s
performance. Of course, they sometimes also
break functionality in a DAW, for any of the reasons discussed, but it’s
usually not long before
the DAW maker, the OS maker, or both figure
out the problem.
4. Report crashes to your DAW developer.
When we receive a crash report, it’s a high priority and we work very hard to
fix it. I can’t speak
for every software company, but this culture is
pretty pervasive. So if you’re hitting the same
crash over and over, let the manufacturer know.
Sure, we’ve all had frustrating calls to tech
support, but if you can get your problem in front
of the programmers, the result may surprise
you. Speaking as a programmer, I can vouch
that we do want to push that car back up the hill
and see what happens, because we can’t resist a
Dan Goldstein is the Chief Technology Ofﬁcer
of Acoustica and the lead developer of Acoustica’s Mixcraft recording software.