It’s worth noting that a Google “Hangout” is not the same as a “Hangout-On-Air.” A Hangout-On-Air is streamed and recorded via YouTube in real-time. This gives it the potential for much greater reach. A normal Hangout is not streamed in this manner, although it does allow for PSTN connectivity.
This difference is arbitrary, although I’m told it stems from legal concerns about copyright issues that could easily occur if Hangouts-On-Air were allowed to have broad interop capability.
The fact that the VUC uses a Hangout-On-Air has compelled my search for a reliable, high-quality means of interconnecting the Hangout-On-Air and ZipDX conference bridge. Given my long-standing and vociferous support of HDVoice even the PSTN access provided by a plain vanilla Hangout is troubling. Connecting via a pure IP means, like SIP URI, would allow interconnection with much better audio quality.
VUC founder Randy Resnick has been successfully connecting the Hangout-On-Air to the ZipDX conference bridge using an audio setup the betrays his history as a musician. His audio mixer is able to provide two mix-minus feeds so that he can act as a source for both services, without inducing aggravating echo or feedback.
He’s done an incredible job of managing a fairly complex setup for a long time. My aim was to arrive at a method of interconnecting the services that is independent of the host location and resources. This would make it easier for someone to relieve Randy on those rare occasions when he goes on vacation.
Further, I can see value in the interconnecting the services in a manner that is independent of any single participants engagement in the call. Chrome can be cantankerous, even fragile some days. It would be more reliable if the instance of Chrome that was interconnecting the services was not also providing my presence in the Hangout, monitoring the IRC channel, twitter, etc.
That means that the process connecting the Hangout and ZipDX would occupy it’s own “seat” on the Hangout. This is actually most ideal. It allows a visual proxy for that connection made to represent the audience on ZipDX, adding a visual cue to when an audio-only participant is speaking.
As described previously, a physical audio patch worked, but with some issues. This suggested that a virtual audio patch of some sort ought to be more ideal.
Jacked: Beyond Doritos
I did some initial experimentation using Jack for Windows but this proved fruitless. While in theory Jack is able to provide this kind of thing, it seems only applicable to programs that use the ASIO audio driver. In my realm that meant that I could use it with my Adobe suite or Audacity. Unfortunately, neither Chrome nor any of the soft phones I have use ASIO, making Jack a non-solution in this case. Also, I found Jack to be unduly complicated to set up.
The ABCs of VB-Cable
Seeking further I found VB-Cable, a virtual audio device driver for Windows. You might be forgiven for thinking that “VB” implies Microsoft’s Visual Basic. VB-Cable is from a French programmer named Vincent Burel. Hence the VB. VB-Cable is donation-ware, so if you decide to use the software, offer what makes sense to you.
VB-Cable is a virtual audio device driver. Once installed it provides one playback device and one recording device to Windows. That means the ability to patch the output of the Hangout to the input of a soft phone. It’s half the required solution.
VB-Audio also offers two additional drivers; VB-CableA and VB-CableB. These are simply separate instances of VB-Cable that can be separately installed. Collectively, they provide three independent, virtual audio paths. We need only two to cross-connect a Hangout to ZipDX. That’s one path in each direction.
To install the drivers under Windows 7 you must select the correct installer, 32 bit or 64 bit, right-click and select run-as-administrator. There’s a separate installer for each of the three drivers. After the installers have run it’s a good idea to reboot the system.
Once you have at least two of the VB-Cables installed you can visit the audio devices control (Control Panel, Sound) where on the Playback tab you’ll find two new devices; Cable Input and Cable-A Input in my case. On the Recording tab you’ll find a similar pair of outputs.
To cross connect the Hangout-On-Air to ZipDX I used Chrome and Eyebeam v.1.5. Eyebeam is an older release but it’s the one that ZipDX offers to customers who need a soft phone.
In Eyebeam I visited the Options menu and selected the Audio Devices settings. There I set the “Speaker Device” to Cable-A Input and “Microphone Device” to Cable Output.
I also started by disabling all echo cancellation, auto gain control and noise reduction. This is an entirely virtual interface so echo and noise should not be a factor. Auto gain control might prove useful, but it would be best to start without the added complexity.
In the Hangout Settings I setup an opposite arrangement. The “Microphone” source was set to “Cable-A Output.” The “Speakers” output was set to “Cable Output.”
Thus the interconnection of the services was initially setup as shown in the following diagram:
Based upon the terminology of routing a “speaker output” to a “microphone input” you might expect to have some trouble with level mismatching. However, that doesn’t happen since all this routing happens at the device driver level. At this point the signals have already been taken to line-level and digitized if necessary. It’s all data streams at this point.
My intention was that this process would run on a freestanding PC (my laptop) that had a wired network connection. Additionally, I would join the Hangout using my desktop PC. That would keep the interconnection process wholly separate from my usual activities.
It also meant that I didn’t need to monitor/hear the process that was running on the laptop. In fact, if it were audible it would create echo into the Hangout via my headset. Thus I left the laptops speakers set as the default audio playback device, ensuring that the soft phone and hangout could not be heard through the laptop.
If you need a convenient way to monitor audio in each direction of the interconnection you can set either Cable or Cable-A as the default audio device. That will result in the select stream playing to the computers speakers.
Note that each stream is just one direction of the conversation; from the Hangout to the conference bridge, or from the conference bridge to the Hangout.
A Visual Proxy
Since the laptop interconnecting the two services occupies a seat on the hangout it’s video stream will be shown whenever anyone on the ZipDX bridge speaks to the assembled audience.
In order to have a way of indicating this visually I created an image with a ZipDX logo, then used the Hangout’s desktop sharing function to share that image instead of the laptops built-in webcam.
This worked well-enough, but in hindsight I might do it differently next time. On January 24th Goggle’s Hangout function was having some difficulty. My laptop was dumped from the Hangout several times during the hour-long call.
Each time it was dropped it automatically tried to rejoin the Hangout, and did so in about one minute. However, each time that it rejoined the desktop sharing function that was displaying the logo image needed to be reset. It would be more ideal if I could use a utility like Sparkocam to send the Hangout a logo image as a virtual webcam feed. That way the only visual available to the Hangout would be the logo.
Alternatively, I will probably try using the ZipDX Dashboard as at least part of the visual representation of the conference bridge into the Hangout. This will give an indication of who is actually speaking when someone on ZipDX takes the floor to pose a question or offer comment.
The Results…So Far
From the outset this method of connecting the two services has worked very well. The latency presented by the process appears to just the result of the distance to/from the services. That is, the client-side handling of the audio does not induce any additional delay.
Nor does it result in any loss of quality. A casual poll of VUC regulars, a tough and very experienced crowd, has shown that people are happy with the result. In particular, Bob Bowles of Vivox was involved in some initial test calls, and has been very positive about the results.
As we go forward using this technique I hope to gather more details about additional audio routing such that I can take accurate measurements of call quality using software-based tools.
What Comes Next?
Using the VB-Cable virtual audio device drivers has proven to be a good solution, but along the way I’ve discovered a couple of additional potential solutions. I intend to give these try to see what additional flexibility they might bring to the situation. There’s certainly more to follow…over the coming few weeks.