So, I got a little obsessive. This is the first of a couple of posts on the challenges of setting up a performance rig that incorporates both iThings and hardware synthesizers — particularly older hardware synthesizers. I’m basing it on problems I ran into with the “semi-portable” rig that I use for out-of-town collabs, and as one part of my home studio. My rig uses a Focusrite Scarlett 18i20 to perform inbound and outbound digital/analog conversions, an iConnectMidi4+ for connecting iPads, and a Linux-based laptop computer used mostly for routing but occasionally as an effects rack and dynamics processor.

I’m going to focus on two main topics: USB gremlins, and tempo synchronization — I think they’re the things that others will encounter most frequently. There are probably others and I’ll hope for suggestions in the comments. I don’t claim to have super-deep knowledge on either topic — and those who do are encouraged to offer corrections and additions in the comments, including calling me out when I’m flat-out wrong. We’ll start with USB gremlins.

USB

For those impatient with details, I’ll offer 5 rules of thumb that are likely to solve 95% of your USB audio problems:

1) Always connect ADCs and DACs directly to a host computer, never through an intervening hub. Shriner’s First Law — “Interfaces HATE hubs” — is true, for reasons we’ll get to below.

2) If you use hubs, use powered hubs, and plug in the power (yes, they’ll operate without an outside power source, but that takes away the magic)

3) Minimize USB cable lengths, and use cables that have ferrite cores to reduce interference — those are the lumpy things at the ends of some cables (you can also get snap-on ferrite cores for your existing cables, cheap).

4) Ensure that sampling rates on all devices are (at least) set the same, if not synchronized to one source.

5) Always connect all devices to a single, grounded power source.

But sometimes it’s necessary to break these rules. For example, laptops now seem to have at most two USB ports, and that’s not likely to be enough for everything you want to do without an intervening hub. And in any case, understanding a little bit about where these rules come from will help you diagnose any problems that come up.

Let’s take these in order.

Hubs and how they’re connected

Failure to detect connected devices, or devices dropping out after they’re connected, usually comes from power problems. USB was originally intended as a communications protocol used between host computers and peripherals like printers and scanners, or disk drives, or other things that have their own power sources. The standard only requires that each host USB port provide 500 mA of power — not the much higher levels required for device charging, for example. Most USB hubs — including those built into the motherboards of host computers — may not be very smart about distributing power between ports that have multiple connected devices making different demands. So power starvation is a real possibility on any device.

The solution is to connect a powered hub, which has two virtues: it gets you more power, and it also invokes a processor that “reconstitutes” the data stream that is coming into the hub before passing it along to the connected devices. As I just mentioned, powered hubs will fall back into a host-powered mode if their external power source is disconnected, thus losing all the advantages, so don’t imagine that you can omit plugging in a wall wart and still get the benefits. Again, even motherboard-connected USB ports can be stingy about this, so be careful.

It’s worth noting that this is not — at least in a narrow sense — a problem with manufacture, though USB hubs are certainly one place where you may not want to cheap out (I like Anker’s products, as do a lot of other people, and I’ve never heard anyone say a word against them). If you read it carefully, the USB standard says, “Hey, we can’t expect anyone to be responsible for what happens when two passive (meaning unpowered) hubs are connected in series”. So don’t do that ;).

Cables

There are two myths about USB cables. One is that they make any difference whatsoever to audio quality. The other is that they don’t. Perhaps that needs a little explanation.

The folks who say, “well, it’s all ones and zeroes, so we’re not worried about noise the way we are with analog audio” are right, up to a point. You can buy cables that are six inches in diameter, have solid-gold connectors, are insulated with dielectrics used in the Space Shuttle, and have all their copper molecules carefully aligned by Santeria practitioners chanting in the dark of the moon in small factory in Brooklyn, and they will not make one damn bit of difference to the audio quality. But all wires can act as antennas, even surprisingly short ones, and the problem gets worse with length. (Back when pterodactyls were wheeling around in the sky, some friends and I discovered that the head leads on Ampex 440 tape decks were exactly the right length to act as antennas for CB radio channel 7, leading to occasional interruption of Shakespeare performances by pimps doing business from cars on the streets of New Haven). So it’s generally wise to keep USB cables as short as possible, and to use ferrite cores to damp down any RFI. You can buy the cores online, for cheap, and snap ‘em on if your cables don’t have them.

And that’s not the only source of noise. Switching power supplies and other electronics throw hash on the wire, and it can be surprisingly loud. The OP-1 is notorious for doing this when its USB connector is used for charging, and in that case the best answer is to stick an audio isolation transformer on the audio output (you can find one at https://www.amazon.com/PAC-SNI-1-3-5-3-5-mm-I…/…/B001EAQTRI/ ). Also, internal ground loops are possible. Generally, a low-pitched hum is likely a ground loop, and a high-pitched one is more likely internal componentry. Most loops can be eliminated by making sure that everything has a common ground, or by lifting the ground using a 3 pin to 2 pin grounding adapter without the 3rd wire connected. Bad audio hash is damped by ferrite cores, and can be tamed with audio isolation as with the OP-1.

A final note: there are cheap cables out there, usually at the drugstore counter, that are intended only for charging and not for data transfer. And there are manufacturers, Apple most prominent among them, who are doing their damndest to proprietize USB cables by adding componentry or non-standard connectors that prevent their gear from being used except with approved cables that cost a lot. A good series of complaints on this subject is here: https://www.cablewholesale.com/…/…/taming_the_usb_jungle.phpand here: https://mashable.com/2012/10/29/apple-lightning-micro-usb/ .

Sampling rates and sampling synchronization

Here, the clock we’re talking about is the clock that synchronizes the clocks used for digital audio conversion (sample synchronization) on multiple devices that are being used together. Problems with sample rates typically show up as clicks, pops, and other obnoxious noises.

This is a very, very complicated subject; it took a fair amount of research to find out what’s going on under the hood. Again, I’ll put out some rule-of-thumb prescriptions and then go into further detail.

The first thing to do is to check that all your gear has its sampling rates set to the same rate. I have actually had pretty good luck taking a “whistling in the dark” approach where I set the sample clocks to “internal” on all the devices that permit me to do so, and let it go at that. My guess is that the only reason that this works is that I’m relying on resampling built into the Linux audio drivers, but it seems to work OK, provided that all the devices that need to be synced are connected directly to the host computer (it might also work if they’re connected to the same powered hub). Eventually, though, you may need to take a more disciplined approach.

In any rig that contains an analog-to-digital converter (like my Scarlett 18i20), you should use that device as the master clock. Under Linux, that means telling the JACK routing and synchronization system that that device is the primary sound card. A good explanation of how to do this with an OS/X aggregate device is here: https://support.apple.com/en-us/HT202000 . Keep in mind that when the OS/X setup talks about enabling “drift correction” it really means enabling resampling.

If all of your devices have word-clock synchronization inputs, you can wire them up and use that for synchronization from the device you’re using as the master sampling clock. Linux audio drivers and OS/X aggregate device configuration software allows you to turn off resampling, which is helpful if you have hardware sync. Typically, this will not be the case.

If you’re running devices that don’t have hardware-based “word clock”, which is most of them outside of high-end studio equipment, you’re relying on USB to do the syncing for you, using methods explained in extreme detail here: http://www.cypress.com/file/122521/download .

Basically, USB does not support the sending of an independent clock signal, but depends instead on reconstructing the clock-ticks from the audio data stream via black magic. As a result, most USB-connected devices (iPads, for one) depend on resampling to correct any errors or drift encountered in the reconstruction. I have a feeling that the success of all of this may depend a lot on the topology of the USB connections involved and on the software drivers themselves.

Extensive resampling has consequences; audio purists claim that they can hear the effects of resampling and maybe they can. It also drives up CPU usage, as it’s computationally expensive. I’ve also found problems with some resampling audio drivers (such as zita-a2j for Linux) either locking up altogether or using insane amounts of CPU, but the problems are intermittent and difficult to pin down; they can also be mitigated by setting the resampling quality lower. Finally, I have encountered problems with the USB firmware on older laptops/motherboards, but that can generally be upgraded without too much trouble; the manufacturers tend to be good about making improved firmware available.

Maybe the best approach is to start by honoring Shriner’s Law and avoid intervening hubs, and then take the whistling-past-the-graveyard approach and see what it gets you.

Other miraculous fixes

There are all manner of devices out there that will “fix” USB audio, particularly if you’re an audiophile with a lot of cash to throw around. None are exactly frauds, and most will produce some improvement given the right circumstances. Mostly, though, it’s hard to see how they can do much good, and there are quite a lot of engineers who have quite a lot of fun debunking them: https://www.audiosciencereview.com/forum/index.php…

Hope this helps. Again, looking forward to comments, additions, and corrections, so have at it…… and please do re-share if you think it useful.