Mix-Master Mike*: Bridging The Bridges Then & Now
Do you remember way back when VUC calls were don using Talkshoe? That was the service that Randulo used to create the VUC, and it remained the primary conference used until the end of 2008. It was in November 2008 that I arranged to have David Frankel of ZipDX make a VUC guest appearance.
David’s visit was unusual in that we used it as an opportunity to expose the assembled audience to conferencing using HDVoice. David was kind enough to provide some licenses for Counterpath’s G.722-capable Eyebeam soft phone. This allowed us to have a dozen people on ZipDX in HDVoice, while the rest of the audience remained on Talkshoe. You can still listen to the archived recording of the call if you’d like.
That event, so long ago now, marked my first experiment at cross-connecting two conference bridges. It took some experimentation to get things working properly, but it wasn’t really very difficult.
At the time I had a Polycom SoundPoint IP650 on my desk, which was then the top-of-the-line HDVoice-capable SIP phone. It is also able to record calls to a USB memory stick. That was an optional feature at the time, but became standard when the v4.0 UC firmware was released.
Since ZipDX was accessible via SIP URI it was easy to reach the HDVoice bridge. On a second line I called Talkshoe, adding it to the ZipDX call by way of the IP650.
In essence there were three (!) conference bridges interconnected; Talkshoe, ZipDX and the IP650. As complicated as that might sound, it was actually very well-behaved. There wasn’t any problem with echo or feedback.
Each service or device was built to handle bi-directional audio, including echo cancellation. We captured multiple recordings of the call. In fact, we captured a wideband MP3 recording from the ZipDX bridge, an uncompressed wideband wav file on the IP650 and a narrowband recording on Talkshoe.
Dash forward a few years to last week’s VUC call with Marc Abrams of Mocet. That call had increased complexity since the VUC has for the past year or more used a Google Hangout alongside the ZipDX audio conference bridge.
Where connecting ZipDX and Talkshoe was easily done via SIP URI or the PSTN, Google’s Hangout On-Air does not support any such connectivity. That makes connecting the services substantially more involved.
When Randulo is hosting the call in his home studio he has the requisite equipment to connect the various services in an appropriate manner. My understanding is that he has an analog audio mixer capable of providing two mix-minus feeds; one for Google and another for ZipDX. Since he was on vacation in California last week we needed a solution that didn’t rely upon his studio.
Incidentally, if you want to see a decent explanation of one podcasters how-to for mix-minus check out Chris Fenwick’s detailed description of how he engages a remote host via Skype for his podcast. It’s not exactly how Randy achieves the VUC audio, but the principles are the same.
The requirement for mix-minus feeds is predicated upon the host participating at the point in the call flow where the bridges are connected. If the host is not inserted at that juncture then things can be a little easier, if a bit more hardware intensive.
Since we were to be looking at the Communicator over the course of the conversation we had good reason to use the video capability of the Hangout. Also, I wanted to have fully bi-directional connectivity between ZipDX and the Hangout. There are limited number of seats available to a Hangout-On-Air.
Further, people joining the call from work may not want to participate via video, but that should not stop them from contributing. The one-way, listen only mode that we’ve occasionally suffered is a drag. It’s like the voice-only participants get demoted to the back of the bus.
None of this is anyone’s fault. Randulo does a great job of keeping all the various balls in the air. So much so that we haven’t been pressed to have an alternative readily available. I took last week as the motivation to try to find a suitable process, even if just to satisfy my own curiosity.
Clearly, I don’t have the studio gear to take the approach that Randy uses, but I thought that there might be a simpler approach. I have a pair of old PCs that I have kept on-hand for utility functions. Both are smaller desktop PCs which means that they have audio I/O that includes line-level in and out. I thought that I could put Blink on the older PC and run Chrome on the newer one, cross-connecting the audio, effectively connecting ZipDX to the Hangout.
In a brief experiment I was happy to find that it seemed to work reasonably well. In the hour before the VUC call participants on ZipDX reported decent audio quality to/from the Hangout, with the exception of a persistent power-line hum. The noise was less than ideal, but not a show stopper.
To be clear, these two PCs were connected in such a fashion that there was no monitoring of the audio at that point. The audio levels were adjustable in each direction, but I could only rely upon people on each service to tell me if the interconnection sounded OK.
I joined the Hangout using my laptop, a Logitech C920 webcam
Toward the end of the call, which ran considerably longer than expected, Chrome on the #2 utility PC dropped from the Hangout. That caused the ZipDX audience to lose the conversation for a couple of minutes. I restarted Chrome, rejoined the Hangout without too much trouble.
Whatever the approach, there’s clearly a lot of extra effort required to connect a Hangout-On-Air to another service. It doesn’t really matter if that other service is a single telephone, traditional conference bridge, Skype or whatever.
This could be so much easier if Google showed some interest in interoperability. The lack of interoperability leaves an opening for someone else to do it better.
* my siblings are the only ones who call me “Mike.”