Livestreaming requires a lot of computing power — particularly if we are trying to do all the work with one computer.  To give an example of pushing things to the limit, I’ve done a livestreaming show with a single Mac mini handling collaboration (via JamKazam), my audio interface, the OBS streaming software, and graphics generation (using G-Force).  That is asking for trouble, and of course I got some.  The solutions I found are the main topic of this post, but first let’s look at the possibility of prevention.  

An ounce of prevention

There are ways to avoid the problem altogether. 

The most radical is simply to avoid video altogether.  People have been listening to the radio for a long time, and they still do.  A lot.  Obviously, it’s nice to see who’s playing and what they’re playing, but all too often in these days of lockdown the video isn’t offering much value in return for the effort involved.  Bad shot-framing, bad lighting, the use of phones and tablets as cameras — all these are, to my eye, worse than nothing.   I can imagine something a lot better than a lot of the stuff I see in livestreams, and maybe you should let me just turn on the Innertoobz Radio Thang, close my eyes, and do that.  

Yeah, OK, I didn’t think I’d get far with that argument.  A lot of people think that it’s just not live performance if you can’t see it, and of course I’d prefer to.  So the next thing is to think about how you can divide up the computing task.  In a perfect world with an unlimited budget, you’d have a computer for graphics generation, a couple of HD cameras offering HDMI outputs, a computer to handle your audio interface, and a combination switching and streaming device to switch between cameras and graphics, and actually put out the livestream itself.

But of course you’re not doing that

At least, not at first.  Most people either don’t have $2K or more to spend on a rig like that, or would not want to do so without first trying something a little more modest.  So this post is for the folks like me who wanted to give all this stuff a whirl using a single machine — and then found out that the first problem was with audio quality.  Elsewhere, I’ve done a series of posts on livestreaming that focus on working with Jamkazam, on setting up a streaming rig, and so on.  This one is about what to do when things go wrong — and the first place that usually shows up is crackly audio.

Resource starvation

Problems with audio noise (as opposed to outright audio failure, or screeching, howling stuff that comes from misconfiguration) are usually the result of something or other being overwhelmed, often because multiple subsystems are participating in an overload.  This kind of resource starvation happens most often with the host computer’s CPU, but might also be a problem with USB bandwidth, or sometimes with Internet bandwidth going to the streaming server.  Because no one subsystem is creating the problem all by itself, this type of problem can be hard to find.   Solving it might be as simple as taking a couple of preventive steps, or it may take a little more effort and tweaking.

Three things to start with

• Make sure the audio problem you have is not, in fact, a problem being generated by your rig before the signal reaches the streaming setup.  This seems an obvious thing to check, but when you’re nervous about dealing with an unfamiliar process it’s easy to overlook.  Don’t ask me how I know this.  For preference, hang an external powered speaker on the actual stereo feed you’re sending to the streamer — sometimes, complicated routing setups will end up with your headphones getting something different from what the streamer is getting, so be careful.  If you’re using an iPad or computer as part of your rig, you may want to look at the section on buffers below.
• Make sure you’re using a hardwired connection to your Internet router.  WiFi just won’t cut it.  Now, a lack of Internet bandwidth is probably not going to cause audio crackle, though it can, but it is going to create problems that are sufficiently distracting to make it much harder to find the audio problem.  Bottom line: don’t use WiFi.
• Make sure that your audio interface is plugged directly into the USB port on your host/streaming computer, and not running through an external hub.  There are about 10 jillion things that can go wrong with USB audio if  you do run it through a hub.  Most aren’t subtle, but some are.  There’s an explanation here.

Dealing with crackle

Often, “crackle” happens because the host computer can’t process audio fast enough — the crackle comes from what are, in effect, rapid-fire dropouts.  There are four main reasons for this:

• Improper setting of buffers.
• Unnecessary (and usually unintentional) resampling
• USB bandwidth starvation
• Streaming software
• Something else is eating the CPU, usually graphics.

Let’s take them in order.

Buffers

Sound on Sound offers a very nice explanation of buffer-setting here.  There are a couple of things to keep in mind, which basically come down to the fact that livestreaming is not studio recording.   Given that you’re about to take your audio and video signal do the equivalent of jamming an elephant through a keyhole, there’s no reason not to set your sample rate down to 44100 and increase the buffer size to something comfortably huge like 1024.  Yes, setting the buffers larger will introduce some latency, and if you’re using JamKazam you may not want to be quite so heavy-handed as I’m recommending, but in the greater scheme of things sample rates won’t matter much to the ultimate quality of what your audience hears.

Resampling

In an effort to make things easy for naive users like me, many if not most modern operating systems have audio setups that automatically start resampling if they detect a mismatch in sample rates between the audio source and its destination.  Resampling like that is really expensive computationally, so you probably want to check that everything is matched up, especially on the host/streaming computer’s routing system, your interface, and whatever software or device you’re using to do the streaming.

USB bandwidth

I know, it’s kind of a leap to think that USB even has bandwidth, but indeed it does. It helps to remember that USB was originally designed to connect slow-moving peripherals like printers and has subsequently been abused in aid of just about any purpose you can think of.  I discuss this elsewhere , but the bottom line is that USB is a limited resource.  The way in which USB hubs work, and the way that computer designers implement multiple USB ports on a machine, make it sort of hard to troubleshoot.  One quick and dirty way to test is to simply unplug any cameras or other USB peripherals (not your audio interface, of course) from your host computer and see if the problem clears up.  But to do a really decent test you’re going to need some kind of USB diagnostic program.   They exist:

• For Windows, use
  • This for Windows 7
  • This for Windows 10 (you’ll need to do some reading)
• For OS/X, use this
• For Linux, use this

You might be wondering if this is really a thing — I assure you, it is.  I had an older ThinkPad I was using as part of a live rig at one point that just died a horrible, panting death every hour or so, and that turned out to be the problem.  Even more interesting: it wasn’t a hardware limitation, but a firmware problem, and an upgrade to the BIOS fixed it in a jiffy.

Streaming software

Trying to stream at too high a bit rate causes problems both for your Internet connection and for the computer doing the streaming.   I confess this is not something I understand real well, but I did find this article helpful: https://blog.mobcrush.com/how-to-choose-the-right-bitrate-for-your-stream-9864ce322a9b .  

Something else

Where by “something else”, I almost certainly mean your graphics processor.  This isn’t likely to be an issue unless you’re running a music visualizer like G-Force or ProjectM as part of your livestream.  If your video card does not have its own GPU (or the software can’t take advantage of it), there’s not a lot you can do.  But some visualizers do allow you to decrease their sensitivity to the music, set re-draw rates lower, and do other things to lower the performance demands made by the software.

So, that’s all for now.  I’ll happily respond to questions in the comments if I can.