The Basic Audio Trouble Shooting Process

Troubleshooting Examples
Got Ears?
Frenchman Jean Auscher invented this acoustic navigation device in case of radar failure.
Image Courtesy Of The Douglas Self Site.

Notes:

T.=Technician   A.=Assistant Engineer   C.=Client

Examples:
Complaint:


A. "The NS-10's aren't working." (small speakers that sit on top of the console)
T. "What would you do to find the problem?"
A. "Well, I guess I'd check the amp and the wires coming from it. Then maybe I'd replace the amp."
T. "Did you check the speaker fuses."
A. "No."

Real Problem: Two blown speaker fuses.

Conclusion: The assistant made a good attempt to solve the problem, but tried to get too complicated before trying the simple things first.

Complaint:

A. "The tape machine tension needs to be adjusted because our 14" reel of tape is slowing it down."
T. "How old are these tapes?"
A. "About 10 years."
T. "Did you check the heads?" (for dirt)
A. "No."

Real Problem: Totally oxide-caked heads.

Conclusion: The assistant had the right idea, but in the wrong direction. The tension was sufficient for normal operation, but the tape was depositing so much oxide on the heads that there was too much friction to overcome in order to play the tape at the proper speed. The first thing to check when a tape slows down or stops is to see if it is depositing oxide on the heads. Fact: 'Old Tapes Shed' When a tape sheds enough to stop it from moving across the heads, the tapes must be 'baked' in order to be played.
Complaint:

A. "There a is buzz coming out of the monitors."
T. "How would you go about solving the problem?"
A. "I guess I'd check the speakers and the amp, then maybe the wiring."
T. "Well, what are you sending to the monitors."
A. "The stereo buss."
T. "Let's start muting the channels on the console one by one to see what happens."

Real Problem: Noisy EQ on a channel module.

Conclusion: The assistant was going in the totally wrong direction here. Generally speaking, when you've got a hundred or more inputs going through the console to the monitors, a buzz will most likely be coming from one of those signals and not the monitors themselves. In the process of muting the channels one at a time, the offender was eventually discovered. Once the offending module was found, a quick press of the EQ button to remove it from the circuit revealed that the noise was coming from the EQ. Now the EQ on that channel can be fixed.
Complaint:
Early 20th Century Acoustical Direction Finder
Early 20th Century Acoustical Direction Finder Used To Locate Enemy Aircraft

Phone conversation:
A. "There's a (60 Hz) buzz coming from the stereo buss."
T. "Is it coming from any one module?"
A. "No, it is still there even when all the channels are muted."
T. "Well, everything was fine yesterday and even earlier today, you must have changed something."
A. "No, nothing has changed, we're doing the same thing we were doing yesterday."
T. "You're sure that nothing has changed."
A. "I'm sure."
T. "O.K., start turning off and unplugging all the guitar amps and microphone power supplies in the tracking room and tell me what happens."
A. "No change, the buzz is still there."
T. "You're ABSOLUTELY sure nothing has changed from your earlier setup? You haven't plugged anything in that wasn't plugged in yesterday or earlier today?"
A. "I'm ABSOLUTELY sure that nothing has changed."
T. "O.K. then, I'll be in to figure it out."

Real Problem: The assistant had forgotten that he had plugged in a piece of outboard gear earlier that day without using a ground-lift on the power cord!

Conclusion: The assistant showed good troubleshooting skill by muting all the modules in an attempt to isolate a possible offender. However, if the assistant had answered the second question correctly, I would have told him to put a ground-lift on the device and see what happens. Then the session would have been back up and running in all of about three minutes. Instead, it took two hours before I could get there, about 2 milliseconds for me to notice that they had a new piece of gear in the room, and about another 10 seconds to put a ground-lift on it and walk out. The clients lost a couple hours of wasted time because the assistant was not thinking clearly. Moral: Make sure your engineers can troubleshoot simple problems.
Complaint:

C. "There's a buzz coming from the stereo buss. I've muted all the channels and it is still there."
T. "O.K., let's start by turning off and ground-lifting the new gear."
C. "No change."
T. "O.K., let's turn off and move this computer monitor."
C. "The buzz is gone."

Real Problem: There was a computer monitor that had been setup on top of the console and was radiating RF into the stereo buss. Once it was moved to a new location, all was fine.
Complaint:

A. "The 'CUT' button doesn't work on this module."

Conclusion: The 'CUT' button actually worked fine; when it was pressed it cut the signal. The assistant mistakenly said that the button didn't work when in reality only the bulb was burned out.

Complaint:

C. "There's a buzz coming out of the stereo buss."
T. "O.K., let's try..."
C. "I think it's coming from this piece of gear because it seems to get louder when I unmute it."
T. "O.K., well let's try something else first. Let's have the assistant turn off and unplug those guitar amps out there one by one while we listen."
C. "Hey, it's gone."
T. "Put a ground-lift on that amp."

Conclusion: The client was attempting to troubleshoot the problem but was going in the wrong direction. Also, he was under stress because there was a room full of musicians sitting around waiting, and a producer breathing down his neck as well. I was 99.8% sure I knew what the problem was when I walked in, and even though the client tried to pursue a different troubleshooting path, I had to coax him into letting me try what I felt was proper first, and it when it was solved in two minutes, they were all grateful.
Problem:

A buzzing noise coming out of the stereo buss of the console. Muting all of the channels had no effect. There was no session in progress and thus no client gear that might have been causing ground loops. I then thought that maybe there was an offending module (somewhere after it's mute circuitry). As soon as one module was pulled, the noise went away. I thought it strange that I pulled the offending module on the first try, so I put it back (the noise returned) and pulled another one, and the noise went away. That immediately indicated some type of a loading problem with the console power supplies. As it turns out, some of the filter caps in one of the two power supplies were completely dried out and ineffective. Even though the other power supply was functioning properly, I replaced the filter caps in BOTH power supplies since they were both the same age, and it would have been only a matter of time before the other supply failed, and possibly caused some down-time.

Common Techniques:
  • When troubleshooting a piece of gear that is malfunctioning.
  • ALWAYS check the power supply.
  • Check the voltage values.
  • Check the linearity of the waveforms.
  • Check for DC offset on AC voltages.
  • Check for AC noise component on DC voltages.
  • Check filter caps for leaks or drying out.

  • When performing an A/B swap, ALWAYS swap both the (suspected) bad piece AND the (suspected) good piece. Sometimes you will be double-whammied with a bad piece that was supposed to be good, and that can lead you down the wrong path.
  • Connectors (audio / logic / power supply / etc.) can be, and often are, a source of problems.
  • Semiconductors are usually more likely to fail than resistors and caps.
  • A loss of high-end in an op-amp audio path will generally indicate a drying/dried out DC de-coupling capacitor.

Etiquette:
  • Manuals are a great source of information, but keep them in your shop and don't bring them into the control room when there are clients in there. Clients don't want to see techs referring to manuals. Excuse yourself from the room for a minute or two under the guise of going to get a small tool and quickly and quietly refer to your manual in the shop. It appears more professional and won't reduce the client's confidence in you.
  • When coming into a room to fix a problem with clients around, always bring the absolute minimum of tools. Clients don't want to see a bunch of tools, and the less tools they see, the better they feel about the repair being done quickly. The level of client stress rises exponentially with the number of tools brought into the room.

Words of Wisdom:
  • The 'proper' repair is not always the most thorough and complete repair, but instead the one that will get the session back up and running as quickly as possible. We all want to be as thorough and complete as possible and to do things the 'right' way. But what is most important, however, is incurring as little down-time as possible. If that means doing a quick and dirty solder job with a little piece of tape around it, then so be it. You can always go back in after the session is over and heat-shrink it for a trip to the moon.
  • Try the simple things first, even if they seem 'stupid'. Simple, 'stupid' things take VERY little time and will either fix the problem, or eliminate them as variables. Which brings us to another point...

Eliminate The Variables
  • Just as you can't do a level calibration when there is more than one pot in series with the audio path, you can't solve or isolate a problem when there is more than one variable in the chain. In systems troubleshooting, this means reducing the signal path by eliminating pieces of gear from the audio chain. When troubleshooting a module, this means eliminating sub-sections of the module from the chain and/or assigning different inputs/outputs to further reduce the number of variables in the chain.
  • Learn the idiosyncrasies of the gear you are responsible for. There will be certain problems that may seem totally baffling at first. There will also be instances where the solution may seem baffling as well. The means to the end (how you fixed it) is not as important as the result itself (the gear working properly). After time, however, you will have stored these away in your head (or maybe on paper or in a database) and will be able to recall them when the same or a similar problem crops up. That way you won't have to re-invent the wheel every time something breaks that you've seen before.
  • Always verify problems yourself before trying to fix them. While it is important to have others tell you what they know about a problem, don't let their words be cast in stone. If you take for granted what someone tells about a problem, it may lead you down the wrong path if they are incorrect with their information.
  • Train your engineers in basic troubleshooting. It is important that they be able to fix, or at least troubleshoot simple problems on their own. The ultimate goal of the studio is to make the sessions run smoothly (i.e. generate studio revenue). The more problems that the engineers can handle, the less downtime there will be, especially if you (the technician) are not in the facility.

BACK DOOR!Back To Home Page Back Up To The Top

Web Page Design Is Copyrighted ©1999 Through By Barry Rudolph