Yesterday, the invaluable Ken Palmer raised a damn good question: how can we alert performers that their livestreaming performance has somehow gone off the rails? As in, “we can not hear or see you” or “the audio is badly broken up” or “the images are frozen” off the rails? Speaking as someone who’s now had this happen, twice, I have a couple of things to offer. As usual, there’s a short version and a long version.

The short version: you need a pre-arranged friend in the audience — one who is ready to alert you if something goes wrong — and a device that supports SMS messaging — namely, your phone. And you need to set up that device so that a) you can see it while you’re playing and b) a message from your friend will show up without you having to do anything like unlock a screen or press a button. Anything that Friend sends to you should be immediately visible without you having to touch the device.

The long version: you need preparation, testing, the above-mentioned alert system, and a strong dose of realism applied to different parts of the process — and to the audience as well. The alert system is the smallest of your problems, because you really should be trying to make an alert system unnecessary. I’ll start with realism as it applies to the system as a whole.

Here are three important characteristics of the Internet and its complex underlying technology:

• Shit happens.
• Shit happens unevenly for different consumers of a livestream.
• Much of the shit that happens is beyond the control of the performer.

I say this as someone who had a JamKazam session drop unexpectedly in mid-rehearsal last night, in a way that was unrecoverable for at least ten minutes, and was no fault of mine or the guy I was playing with. And while the underlying technology of the Internet was designed to route around localized technical failures, it can’t do that if a car crash two blocks from the performer’s house takes out all their internet access. This is just reality, and the solution can really only be found in etiquette. We need general agreement in the community that no interruption should be treated as a catastrophic failure until it’s gone on for, say, ten minutes. At that point, but not before that point, everyone listening should give up and go home.

Second, there’s realism as it applies to the audience. The performer is playing a show. They are not reading the comments in the chat panel. Even if they were trying to read the comments in the chat panel, they would not be able to follow them, so they’d have to read a half-page of text every time they tried to check. Add to this the fact that the livestream is anywhere from 20 seconds to 90 seconds delayed from what they’re actually playing, and it’s just cognitively impossible. They’re not paying attention to you because they can’t. It’s that simple. Hence the need for Friend and a dedicated channel that is in their field of view and can be read quickly and without using their hands. We should probably add that communication via that channel should be…. economical. No atta-boys, no comments on the weather, nothing other than an occasional “sounding good” or “I can see your underwear”.

Incidentally, there are a few alert systems that are meant for field engineers and people like that, mostly people who get messages like “the reactor is melting down”. They seem to be priced accordingly. I suspect that a good SMS text app that has the ability to signal incoming messages from particular people is really all that’s needed. In other words, just a modern cell phone with the ability to assign different SMS alert tones to different people. I think you can probably get one of those in a box of Cracker Jacks now, if you don’t already have one.

Then there’s realism as it applies to the various things that are under the control of the performer. I have a couple of observations about this — and they could run to several pages, but I’ll try to keep it short. As briefly as possible:

• You need to be very conservative about compute resources. I’m now running separate computing devices to run the JamKazam session, to generate graphics, to play prerecorded video, and to handle the video switching, stream generation, and recording (one device for all three).
• You need to do end-to-end testing and you need to run it for a period of time — I would say at least an hour, done earlier in the day of a show, and for a brief period about an hour beforehand. And by “end-to-end testing” I mean “streaming from your actual setup with the actual graphics and video setup you will use to the exact Twitch channel that you’ll be streaming to”. Sometimes it isn’t possible to use the exact Twitch channel — but in that case you should use another Twitch channel that is different only in its stream key.

Let’s unpack these a bit.

I am a cheap bastard, and pretty good at repurposing old computers, so I not surprisingly tried to cut as many corners as I could when putting together a streaming rig; at one point I was running everything on a not-very-capable Mac mini. As some of you know, that was successful some of the time, but also resulted in some rather spectacular crashes. Because many of those seemed to be related to the way JamKazam was treating the machine (both in terms of its takeover of the audio system and in terms of CPU consumption, especially when using multiple cameras within JK), I decided that it needed to be isolated. The most practical course at that point was to get an actual video switcher (in my case, an ATEM mini pro) which I could treat as the “second monitor” for both the JamKazam machine and for a graphics generating computer. If I weren’t using JamKazam and wanting to use its video system to show my bandmates, I think I could get by without the switcher — all I would need to do is run OBS on a computer with enough horsepower to run OBS with USB cameras but no graphics, which is what many people seem to be doing. Also, for what it’s worth, I think that using a simple class-compliant audio interface like the cheap Behringer UCA-202s I’ve recommended elsewhere will reduce CPU load and make life a little easier all around.

Adding graphics probably means adding a switcher; they eat so much CPU for live generation that you really need a second computer with an HDMI output. However, if you have visuals that don’t need to respond to the music in real time, you could prerecord them and just play them back with VLC through OBS. With the ATEM, I can use a $35 media player that is a separate unit that has an HDMI output; that’s what’s showing all the scifi movies (by the way, my first attempt at doing a show with that rig is here. I’m now in the process of making improvements to the whole thing, but it wasn’t a bad first attempt).

There are a million ways to configure such things, many of them creative and interesting in the results they produce. The aim should be to keep CPU utilization on any machine in the system of machines you end up using under, say, 60%. Yeah, I know that seems overly strict. But I’ve also seen how fast resource-starvation problems can spiral out of control — and that’s why I suggest testing a livestream rig for at least an hour just to see how it reacts to different loading and network conditions. Test, test, test, test, test.

Do all of that right and you won’t need an alert system — but you should still have one, simple, easy, and right in your field of view — and to me, that seems best accomplished with a well-trained Friend and a phone.