DAWs, computers, hardware, and woes. Part 1: HardwareHardware is not difficult to troubleshoot once you have some basic concepts under your wing, and a reasonable amount experience under your belt. Most hardware troubleshooting is a matter of understanding some fundamentals about hardware and how it can be set up, arranged, configured and updated.
Start with a good approachIn the Introduction section of this thread, I offer up a fundamental approach to troubleshooting. This approach applies to every part of this thread, including hardware. Part 1 assumes the Introduction has been read and assimilated, and offers some hardware-specific advice one can use during the troubleshooting process.
Remember, isolating the source of the symptoms is very important. Remember that cables, internal and external, do occasionally go bad. While it's not so frequent that you should default to cables first, disconnecting cables can help in isolating the source of the symptom. Please make sure you read the owner's manuals for all your hardware and understand the ramifications of disconnecting cables prior to doing so. In the
Still 'broken' section I discuss isolation further.
-------------------------
Start FreshWhen working with hardware, particularly hardware that is connected to other pieces of hardware or computers, the first place I always start, without exception, is: does the hardware still fail when started from a clean state? In other words, if the piece of hardware in question, and all hardware connected to it (including the computer), are dead cold powered off, do they still fail when you turn them back on? Powering off and powering on is called 'powercycling'.
Why is this important? Hardware electronics is extremely complicated, much more so than I'm willing to learn myself. But you don't need an engineering degree to understand the basic troubleshooting of digital gear.
The operating condition that a device is in while its powered on and in use can be called the state of the system, or system state. This can be as simple as, for example, what patch is currently selected, or what channels are routed where. On most devices, the system state will most likely not be maintained if the system is powered off. Digital gear most often uses some kind of RAM to store its state while in use, and when the device is powered off, the memory (provided its not flash ROM) is essentially erased, or 'zeroed out', because it requires power to maintain its data. This is assuming, of course, that the device does not use a standby mode and there is not some kind of process that keeps power to the memory during standby mode. In that case, putting the device in standby, then unplugging the device from power should have the same zero-out effect.
In short, if the device works as desired after it is given a fresh state, it is likely not broken per se. It may just be put into a bad state because of some other adverse activity.
Why do other components need to be powercycled as well? Digital devices (and sometimes analog) that communicate with each other usually depend on some kind of communications protocol for their interactions. On complex and feature-rich systems, the communication protocol may even include language for altering the state of the system. If a device is sending unwanted data to another device on the chain, it may appear that the receiving device is broken, even if the unwanted data is adhering to the protocol specifications.
A good example of this is the postscript printer. Postscript is a language that tells a printer what to print, how to print it, and other printing operations. It can also tell the printer to print double-sided, manually feed, etc. If corrupt data is sent to a postscript printer, it frequently results in the printer spewing out pages and pages of 'garbage'. In the older days of postscript I dealt with this on a daily basis. Rumor has it you can use postscript to tell a printer to jam itself.
An example closer to home is the MIDI protocol. MIDI not only sends data for playing notes, changing patches, etc, but it also can control faders, change a timepiece routing, update firmware, or any other device feature designed to be used with the MIDI protocol. Another example close to home is the D-Command, which uses (what I believe is) a proprietary protocol over ethernet. The D-Command does all of its interaction between mixer and communication using this protocol, and sends data into the ProTools DAW. Despite its majesty, even the D-Command needs a good powercycling once in a while
This issue is especially important when the device is controlled by a computer, e.g. audio interfaces, etc. Computer-controlled devices are frequently accompanied by software called 'drivers' (which most of you know of, I'm sure), that run in the background and facilitate communications between the application, computer and the hardware device. Software is conceptually identical to hardware in that software has components, communication between those components, a framework to operate in (e.g. electrical wiring in hardware, digital 'wiring' in software), a live 'system' state, I/O, and of course, the ability to give you a tension headache. Any kind of issue that can affect hardware can also affect software.
Software drivers, therefore, can also be in a bad state. Depending on the protocol, this bad state can 'infect' the hardware it is driving, which can in turn, potentially adversely affect other devices in the communications chain.
Not powering down the computer that drives the hardware can cause your hardware to return to its bad state. I have seen this happen dozens of times, and I require practice all my lackeys to make sure that a clean state power-down includes a computer shutdown. Back to the printing example, if you have a print server serving a bad print job to a printer, it doesn't matter how many times you powercycle the printer, the print server will continue resending the job until the job is 'successfully' printed, or until the job is deleted from the queue.
Software drivers can also be outdated. Make sure you have installed the latest driver software from the manufacturer before calling the hardware broken.
One other note about software drivers. If the software application that uses the driver crashes, or is force quit, the hardware device could be left in a bad state.
Relaunching the application may not return the hardware to a fresh state after a crash.Persistent Bad State. Sometimes powercyling a device isn't enough to refresh its state. Flash ROM is gaining popularity among manufacturers, and many digital devices use Flash ROM to store system state and settings between powercycles. Therefore, problems arise when the stored data is corrupted or unusable, as turning the device off and on does not help. This is why most manufacturers include a way to reset the internal storage of the device to the state it was in when it shipped. This process is usually called 'restore factory settings', 'hard reset', 'reset to factory defaults', etc. On more complex setups, you can continually corrupt the communications (and thus put multiple devices in a bad state) until a hard reset is performed, followed by a proper shutdown. Please read the owner's manuals for your device to find out how to hard reset your hardware.
Persistent bad states can also result from adverse activity created during regular use, that only manifests in certain situations. For example, I'm using a CD-burning application, and every time I try to burn a data CD in Mac-only format, the CD-writer becomes unusable. Or, my 96 I/O works great until I use an HD plug-in with a certain setting checked, then it stops working. In these cases, you are most likely at the mercy of any firmware updates or software patches available. Otherwise, you must send a bug report to the manufacturer with as much information as possible, so that they can create a patch for the problem. Then you sit and wait. Have fun with that
Power Up! One last thing. Sometimes the order in which devices are powered back up can affect their behavior. With modern equipment and responsible software driver engineers, this is less of an issue. But you will occasionally find older equipment or drivers that do not respond well when things are not booted up in the proper order. On older computer-driven devices, often the device must be present prior to the driver-loading (i.e. the computer booting). I discovered this in the OS 10.3 days with MIDI devices and timepieces.
Still 'broken'.If the hardware still does not function correctly after all of the above, the next thing to do is make sure that any firmware that is in use on the device is updated. Many hardware manufacturers offer firmware updates for your device, and it is in your best interest to stay on top of these firmware updates. Consult the manufacturer's website to find updates and instructions on how to install them.
Assuming any firmware is current, if the device still does not work as desired, isolate the hardware from all other devices, if possible. Clearly, it's hard to test a 002 when it's not connected to the computer. But a MIDI keyboard, for example, can be operated outside the MIDI chain in most cases. Many other devices can be as well.
Once you have isolated the device (as much as you can), test to see if the symptoms persist. If they persist, you know the source of the symptoms. If they do not, the problem lies outside this device somewhere in the original setup. At this point, add one device back to the setup and test again. Continue adding devices one at a time until the symptom returns. At that point you know that there is some kind of relationship between the newly added device and the device the symptom appears on. In rare cases, it could be the combination of devices that triggers the symptom, and remove one seemingly unrelated device from the setup could remove the symptom. This is quite rare.
At this point, if the hardware is still failing, it's possible there may be something actually wrong with your hardware, and electronics repair might be necessary. Electronic repair is outside the scope of this thread and will not be covered. If the manufacturer does not repair your hardware anymore, and if you do not know anyone who specializes in audio gear repair, contact a professional studio and ask who their repair service is, or who they would recommend.
SummaryIn general, devices rely on power to maintain their state of operation. If that state is corrupted, sometimes powercycling is required to return the hardware to its normal state. Other devices in the setup can contribute to bad states as well, and isolating the source of the symptoms is vital in these cases. Software drivers that drive the device and firmware in the device can contribute to bad states as well, and may need to be updated. Hard resets, or restoring factory defaults can also aid in determining whether the device is broken, or if it gets into a bad state as a result of something else.
