PC Audio 131
Bug hunting can be frustrating, but it can be rewarding when you finally track down the cause and get it fixed.
Bugs in software or hardware can prove incredibly frustrating, both to the developer and to the end user. When PCs are involved the number of possible permutations of hardware, operating system, DAW, and so on, multiply alarmingly. It’s hardly surprising that occasional bugs slip through the beta testing process.
I was reminded of this a few weeks ago after being asked to evaluate some on-line audio tutorials, which in themselves proved to be fine and dandy. However, I was surprised to discover a total of eight minor anomalies with the supplied video player itself after just a couple of hours; such as keyboard shortcuts that didn’t work as described, and progress readouts that didn’t always update correctly. None of these prevented you enjoying and learning from the tutorials, but were certainly a classic example of sloppy programming. Far more problematic are bugs that cause your DAW or indeed your PC to crash, or that corrupt or alter your audio in unexpected ways. I’ve been a software developer myself, so I know just how difficult it can be to totally eradicate bugs, but with my reviewing hat on I’ve also experienced the other side of the coin. Here are a few examples that have crossed my path over the years.
One aspect that’s caught out a few products is forgetting to test thoroughly with both mono and stereo audio signals. So many of us record loads of mono tracks during band projects that developers can also fall into the trap of performing most of their tests with mono files. However, there are times when it’s vital to treat both channels of a stereo signal separately. For instance, I once reviewed a very effective noise reduction plug-in that incorporated a clever auto dynamics mode that altered the attack and release times of the noise reduction to retain the transients while avoiding chirpy artefacts. It worked beautifully on mono tracks, but as soon as I tried it on a stereo file the image wandered about all over the shop. Auto mode turned out to be only coded to the left hand channel, while the right hand channel still relied on the less effective manual settings of the attack/release controls, so each side of the stereo signal was unexpectedly getting different noise reduction dynamics.
I noticed a related but rather more obvious issue with a rather natty envelope-swept resonant filter plug-in. Similar to the last, it worked beautifully in mono, but the envelope code was hard-wired to the left hand channel so the filter sounded most odd with stereo loops because it completely ignored what was happening on the right channel. In this case, a mono sum of both channels should have been used to create the filter envelope. Both were easy fixes once I’d emailed their respective developers. There was no need for me to point out the bugs, as I’d received and tested the bug-fixed versions before my reviews were published.
Sometimes bug fixes aren’t so easy, especially in the case of hardware. On one audio interface I was sent to review I soon noticed a subtle lack of bass end, and my tests bore this out, the unit measuring a very poor roll-off of -3dB at 45Hz. I passed on my results to the UK distributors, who were adamant that I must have made a mistake, as several hundreds of this interface had already been bought and were out in the field, and two other positive reviews had already been published. The next day they phoned back full of apologies, confirmed my findings, and explained that the designer had inadvertently used suitable interstage capacitor values for a single electronic stage. They had forgotten that the frequency response becomes cumulative when an audio signal passes through multiple electronic stages, each one of them rolled off a little more from both the top and bottom of the spectrum. In this case, the production line had to be halted, all interstage capacitor values increased to extend the bass response, and every interface already in the field had to be recalled and replaced free of charge.
Another interface arrived for review with excellent measured frequency response, but a strange high-end anomaly that was most noticeable on hi-hats. This turned out to be the interface drivers, which had inadvertently offset one side of the stereo channel by one sample compared to the other. Thankfully, this was a much easier fix, and an updated software driver arrived within a couple of days to cure the problem.
So what should you do if you think you’ve discovered a bug in one of your PC audio software or hardware purchases? Well, if the problem occurs in your DAW, and the offending project is still running, immediately re-save it (but with a different name, such as MyProject-bugged-version), so that you have something to re-load if further investigation is needed to narrow down the cause. Even a photo of your screen showing the problem may help. The vast majority of developers will be quite happy for you to report a bug directly to them, either personally by official email, or on the most appropriate internet forums (either that pertaining to the DAW itself, or the plug-in manufacturer if you suspect that to be the cause). Do scour the forums first though, as someone else may have already experienced exactly the same problem and reported it, in which case you can confirm it and wait for a fix.
Don’t go in full of anger, blame and with accounts of your wasted time — this will just put other people’s backs up, as well as putting the developer firmly on the defensive. If it seems to be a new issue, remain calm, and the most important thing to do next is note down exactly what steps you took that resulted in the bug first appearing, and try to repeat them. This is often the trickiest part, but if you can get the bug to appear in exactly the same way every time by following a list of actions, post this information so that others can try it out. This should confirm if the problem is in the software/hardware itself, or whether it only happens with your particular combination of gear. This combo also needs to be described in full; which version of Windows you’re using, which version of your DAW, and any other aspects that seem relevant. Once a repeatable bug has been confirmed, many developers manage to turn around a fix within a few days, although some may wait so they can include your bug fix within the next software update.