I thought I should write out a few more stories about my time working on a Telepresense product, including software and audio and streaming media. I worked on that project for many years, and it gave us many opportunities to apply good engineering practices.

Audio testing

I have been a fan of Information Society since high school. So when we needed audio samples to use in testing our audio connections, I went through my mp3 collection and picked out some random stuff that I liked. I had an old Creative MP3 player I’d carry around with a patch cable to plug in to the sharing jack we had on the table in the conference rooms.

Another key point to this story is that we wanted to have a telephone bridge capability in the rooms, and the best way we could find to do that was to have a land line connected to a modem (yes the old screachy kind) that we could programmatically control to answer or dial phone calls and pass through audio. We had a bit of trouble finding a modem model that would do everything we needed, and the audio through them was questionable. I probably could write another rant about how telephony engineers love to throw away signal. Anyway, I discovered that a certain track or two were great for testing because they could really screw up the modems. Particularly the 300 BPS bonus track from Peace and Love Incorporated could really trip up the modems if they were in the wrong mode. Not that we expected anyone in their right minds to play that through the room during a conference setting, but you want to catch any potential issues before someone figures out how to hack your system.

Visual size relations matter

One of the things that made telepresence “Telepresence” was the geometry of the rooms. The designers worked out the screen sizes and distances from table to screens so that people were as close to life size as possible. And it really does cognitively make a difference. It is a lot easier to forget you are talking to a glass pane and have a real conversation when the person on the other side looks like a person rather than a postage stamp.

It was always frustrating to us to see competitors who tried to copy the designs but didn’t really get it. They would try to cut corners to get ‘good enough’ and miss out on the natural feel. Traditional video conference vendors were the worst about just slapping a big screen at the end of a conference table and pretending it was good (I’m looking at you, Polycom).

There are some related tidbits about camera angle, but I think I have another post planned to talk about that.

Modems for Audio

This story came up as I was trying to think of stories to tell in an interview. The question was, “Tell me of a time when you had to make a technical decision”, or something like that. I can’t remember exactly – there were _a lot_ of questions in that interview. And yes, it directly overlaps with the “Audio Testing” story at the beginning of this blog post. 😛

The story goes that back in Halo Telepresence we originally used a piece of audio encoding equipment that could support a phone line. This allowed the meeting to have remote phone-only participants call in, or to call out to a conference phone line. The Halo software incorporated the phone dialing features in the UI and just passed commands in to the audio device to dial and hang up. It worked well, but the device model line was aging and was rather expensive.

As part of our move to a software defined encoding pipeline, we needed to find a new piece of hardware to use. Our team started looking around and realized the best way to have a self contained device that would just handle a land line phone connection with dialing and hangup was to use a modem. While modems usually are used for data transfer, they (usually) can also pass through an audio signal to the phone line. Another engineer identified a few models with specs that looked like a good fit, and we ordered a few to test with.

These modems have a set of serial commands which can be used to control their mode. They run on what amounts to a simple state machine – off, dial, in call, hang up, etc. For an example list of commands, see here. The command set is pretty simple compared to other devices we used in Halo, so they were pretty easy to integrate with the device models that we used (I should write a long story about how the cool device model stuff worked, but I didn’t write it).

As mentioned above, testing these modems was definitely required. The other engineer was able to run some audio samples through the system and compare the results. We settled on a model that didn’t throw away too much of the high and low range. Though we still had to be careful with that state machine we mentioned, and occasionally had to reset it.