Welcome to London

This post is long overdue. A couple weeks ago I was working on the BSS London’s we installed for connecting our three campuses late last year, and I realized I never got around to talking about the whole thing. This was partly because the audio side of the design wasn’t quite implemented, yet. Everything is in the rack, but we bypassed it all initially to keep things simple for the initial launch. We are probably going to be actively using the London’s pretty soon so lately we’ve been doing some transmission tests and tweaking the setup a bit. When the units were originally installed there were some technical issues that we just didn’t have time to troubleshoot at the time in the run up to get everything live, and the nature of this part of the setup wasn’t something we necessarily needed for the initial startup so it was bypassed. However now that we’re probably on the verge of putting them into play we’re making some final adjustments to everything.

So here’s a quick refresher and some background on the whole thing since it’s been a while since I mentioned any of this. In January we turned on a new system that connected our campuses to each other so that we can basically broadcast live between campuses. Prior to January we would have a message one week at one campus, and then we would play it at the other campuses the following week. My side of the LIVE project was to design the audio routing for the system. Fortunately for myself–but maybe unfortunately for you–I don’t know much about the tech side of the things beyond audio–I believe the connection is over fiber–so you’ll have to dig around on NPCCProduction.org to try and find answers; if the information is anywhere, that’s where it’ll be.

So everything audio is literally tied to video for our transmissions. My campus is the hub, and we have two video sends to each campus along with two video returns from each campus; one send is SD and the other is HD. Digital audio is embedded into the video lines, and we have 8 channels available per send. We embed the same 8 channels on each video line so for redundancy. At each campus a dis-embedder strips the digital audio out so we can pump AES into our consoles.

The 8 channels are made up of what we like to refer to as Tape 8. As the planning for going live progressed, I sat down with all our campus audio staffers to discuss the potentially crazy creative things we might imagine so we could be prepared as much as possible. The ultimate craziness we could think of generally involved some sort of communication between all three of our campuses simultaneously, and these scenarios played heavily into how we decided on the Tape 8 so that in the event of a crazy three-way deal we could get everyone the audio they needed while eliminating the potential for feedback loops between campuses.

90% of the time we just send the Tape 8 from the campus that’s hosting the message to our other campuses where it gets recorded on a video server we refer to as Server Delay. This way each campus can run their service as they please and playback the message a few minutes or a lot of minutes behind the hosting campus; I think most of the time we’re only a few minutes apart, though. Routing a typical Tape 8 from one campus to the others isn’t a big deal in the grand scheme of the complexity of the whole thing, I guess, but we needed routing that was a little more advanced to handle other scenarios.

So we enter my side of the project. We decided on using the BSS London to handle our routing and matrixing for the crazier stuff largely for their flexibility. Going in we knew that we needed the ability to do a 24×24 matrix, and we also thought the added power and functionality of the London’s might come in handy in the future. In fact, one of the biggest challenges in engineering this type of thing is giving yourself room for future growth, and I knew that by using the London’s we could fairly easily expand the system if necessary in the future.

The setup consists of 2 Blu-160’s and 2 Blu-120’s. The 160’s primarily handle digital inputs from each campus with 2 campuses per unit. This way should we ever decide to add a fourth campus, we’re mostly ready for it. The 160’s also take care of any routing and processing that needs to happen. The 120’s have no DSP and purely handle digital output to each campus along with two analog stereo pairs for local monitoring. The setup is actually pretty simple in spite of what might initially look confusing in the software. After six months of letting it sit, it only took a couple minutes for me to get my bearings on the setup again. The heart of the whole program is a source matrix that gives us the flexibility to send any input to any output coupled with a few anticipated presets for fast switching. We also have the ability to monitor any input via some analog outputs which came in very handy a couple weeks ago when we were testing feeds coming from campuses.

So that’s pretty much the audio setup. The real complicated stuff will happen if we get into a crazy three-way all-skate deal just to make sure everything gets routed correctly. And if that happens, I’m sure I’ll have a little something to say about it. In the meantime, feel free to ask me any questions I skimmed over here, and I’ll try and answer as much as I can.