An Approach to Troubleshooting — The top things I would tell my younger self

The more I think about what I wish I could teach my younger self, the more I realize that it probably wouldn’t be anything technical. It would not be any sort of suggestion on what gear to use. It most likely would not even be any sort of mixing tip. It would be how to troubleshoot.

The word troubleshooter was originally given to those who would trace or correct faults on telegraph or telephone lines. In the world of live audio, I would suggest that there is similar complexity. There can be hundreds of sources, connections, signal paths, destinations, and ultimately points of failure. It is guaranteed that things will not always work when you need it to. I have made it my personal goal to be the best problem-solver I can possibly be in any situation I am put in. It is worth noting that this can come as a detriment when applied to emotional situations, but that is beside the point.

I used to think that to be the best at troubleshooting, you had to know everything. I thought you had to read every manual, know every console, and be an expert at all things audio. The more problem situations I found myself in, the more I realized that this is impossible and also not necessary.

Obviously, there are countless problem-scenarios you could find yourself in. If there was always a step-by-step a guide for each scenario, things would be much easier. Regardless, there are a few ideas that, I think, will help anyone in live audio hunt down the gremlin in the system more efficiently.

Here are the three things that, I think, will make you better at troubleshooting in a live audio environment:

- Understand signal flow and gain structure

- Be systematic

- Learn from your mistakes

Understand signal flow and gain structure

The number one thing that was drilled into my brain as an audio student was the importance of signal flow and gain structure. This was taught above everything else. It is the foundation of all systems, and it is the majority of how to create a great mix. It is imperative to understand as much as you can about everything that is happening between the sound being created from a voice or instrument and how it flows into in-ears, the PA, recording devices, etc.

Think about an audio system you have worked with recently and ask yourself: Could I list every device and cable a signal source touches between the stage and the PA? If not, this is a good place to start. I am not suggesting that you become an electrical and computer engineer to learn every possible path an electron or bit could flow. I am suggesting that anything you might physically patch on the day of show, you should probably be aware of what is passing through that cable. It is vital to know as much as you can about every piece of audio gear within the whole system if you end up having to troubleshoot something.

Be systematic

There are numerous resources online on how to be better at troubleshooting. Most of them are broad, but one thing is consistent through all of them. It is important to be systematic. You would rather not waste time trying the same thing over and over just to get the same result. I am very familiar with the feeling you get when everything is set up, you are going through line check, and inevitably one of the instruments is buzzing or not working. The band member blames audio, while audio blames the band member.

For purposes of this example, let’s say you’re testing a keyboard rig and you are not getting any signal. How would we go about fixing it? First, I would determine if the problem is on audio or on the band member’s gear. Utilize a tool such as a Q-Box or SoundBullet to send noise down the keys line. If there is signal, this means that the issue is upstream of where you inserted the noise generator. This is where the knowledge of signal flow is important. You can start in the center of the signal flow and figure out if the issue is upstream (somewhere closer to the source) or downstream (somewhere closer to the destination).

I have a phrase I like to say when troubleshooting issues with stereo signal. Most often, you will run into a scenario where one side is not working, or one side is quieter. Usually, you would swap the left and right signals at some point in the signal path to see if the problem is upstream or downstream. I always confuse myself as to how to know based on that test. Therefore, the phrase I repeat to myself in these situations is “If it Doesn’t change, it is Downstream.”

Think about it, you have a lopsided guitar signal. The left isn’t as loud as the right. You decide to swap the left and right channels coming out of the guitar modeler DI to see what changes. Sure enough, it’s the same. This means that the signal coming out of the DI from the modeler is the same, and the lines downstream of it contain the issue. Time to keep working down the signal flow to find the problem. “Doesn’t change; Downstream”

Learn from your mistakes

The more and more gigs I get to be a part of, the more I fill up my tool belt with experiences that I would not learn in a manual. It is never fun to make mistakes and deal with the consequences, but those are the times that I choose to learn the most. The mistake for me is often far more valuable than the gig I am doing.

For the last few years, I have made a note on my phone that I add all the useful mistakes and things I have learned as I do shows. The list is quite long now. The benefit is that I can both go back and reference these moments, but also the action of writing it down helps ingrain into my brain what it is that I have learned.

Finally, as a bonus, know whom to call when you run out of ideas. They say this business is all about networking, and as much as I love computer networking, the relational networking will take you even further than any google search ever will.

As a bit of an anecdote, I want to share a recent experience that really put my troubleshooting skills to the test. I will be referencing a few specific pieces of gear, but I am in no way placing blame on any person or the manufacturer for this scenario. The point of this is to showcase the troubleshooting process.

A few months ago, the FOH engineer I work with, and I decided that we wanted to try out the Rupert Neve Design RMP-D8 preamps on the artist we are working for. We decided we would put all the band inputs into the RMP-D8 units, and everything else ancillary would go into an SD rack that also handled my outputs in monitor world. We decided the easiest way to integrate this in the DiGiCo world would be to have an OrangeBox with a Dante card. The Dante network is isolated from everything else and consists of the seven RMP-D8 units, two NetGearAV switches with the Dante profile, and an OrangeBox with a Dante 64@96 DMI card. All devices were manually set IP addresses.

The problem came when we loaded in, we started to get noise on several channels on some units, but then it would go away after a few minutes after booting up. This was obviously a strange issue and not something I would expect to happen, but was merely noted as we progressed with load in. By the time we got to line check, we realized that some units were not passing phantom power across all channels. This was a bigger issue because many of our inputs require phantom power.

In summary, the issue is a few boxes would make a noise when starting up, a few boxes would not pass phantom power, and only two of the seven did not have any issue at all. So now, using what I mentioned above, let me break down my thought process on how we approached the noise issue:

- My initial thought is to set aside the idea that five of seven would be broken. Whenever you gave more than a single device acting incorrectly, it is usually best to look at the system as a whole and not assume a bulk of the units are bad. (Troubleshooting is always easier when you have spares where you can swap in and out units to test every part of the system. In this situation, if only one of the units was experiencing issue, I would have started with just that unit.)

- Second, and zooming out, I needed to look at the system as a whole. What aspects of this system touch multiple units? Three things come to mind; inputs from the sub-snakes, the power from the line and UPS, and Dante.

- The easiest thing here to start with is unplugging all the analog components. Starting with unplugging the XLR from the stage box, nothing changes. Unplugging the multi-pin cable into the stage rack does nothing. Finally, unplugging the XLR fan that goes directly into the RMP does not make the noise go away. This rules out the idea that there is any noise coming in upstream.

- The next thing is to test power. Fortunately, these units have dual power supplies. We have one on direct line power from the power distro and one run from the UPS (uninterruptible power supply) which is like a battery backup. From here we can remove one or the other to see if maybe we have a grounding issue or some other power problem. Unfortunately, neither of these fixed the issue. The issues persisted no matter the power was.

- At this point, all this leaves is Dante. Dante is definitely intimidating, and this was my first time implementing Dante into a rig. That being said, this was a simple implementation. It is seven devices outputting into one. Everything in Dante controller looks normal and clock is happy. We did various startup sequences, but nothing changed. We still had a noise issue. Ultimately, it came to our attention that there really could be no way that Dante could cause a problem because the Dante on the RMP only supports output. There is physically no way to input audio into those channels.

- With all ideas exhausted, we decided to call the manufacturer. We were able to speak directly with a technician from RND and walk him through the issue. He quickly asked me to disassemble one and meter the power rails on the circuit board for phantom power. This instantly confirmed why we were having our difficulties. The issue was that on some units, one of the electronics components had failed. This caused two symptoms: one, was that the phantom power would not work on units where this component already failed, and two, on the units where it was failing, it would cause noise until it eventually gave up trying to power that rail.

As you can see, throughout this process, the ideas of signal flow, gain structure, and being systematic are incredibly important. Even though I was unable to solve the issue myself, I was able to skip a lot of redundant troubleshooting with the manufacturer by being able to clearly communicate what I had done already. I can guarantee you, I will always remember this scenario and I definitely understand the RMP-D8 far more than when I started.

I would love to know your best troubleshooting stories.

You are welcome to reach out via email at josh@spacebearaudio.com or on instagram at @spacebearaudio