As the 300 or so people who attended yesterday’s metric webinar know, we had an audio problem about ten minutes into the question and answer session. This failure resulted in me talking to a dead microphone for a minute or two before I realized the problem and fixed it.
The symptom of the bug was two-fold. The red light on the front of the Blue Yeti microphone I was using turned off (i.e., went from illuminated red to uniluminated), indicating a complete loss of power to the microphone. In addtion, naturally enough, the audio display on the GoToWebinar console (which is tucked away toward the bottom of the console, unfortunately) showed no audio and no one talking.
To resolve the problem, I unplugged the USB cable from the PC, then plugged it back in. After resetting the audio configuration on the GoToWebinar console to use the Yeti mike (as GoToWebinar had defaulted back to the Windows default audio), we were back in business. I suspect if I had noticed immediately I could have restored audio within 1 to 2 minutes.
The main culprit is, I suspect, a reliability problem either in Windows XP’s USB drivers or in the audio drivers themselves. I favor the USB drivers as the cause, because the Yeti appeared to have been completely powered down. The failure was abrupt, and cleared itself immediately once I disconnected and re-connected the cable. If the audio drivers had failed, I would expect that clearing the problem would have taken more work. Perhaps someone with a greater understanding of Microsoft’s XP USB drivers could comment on my hypothesis.
I also would suggest to the Citrix people that their user interface is not entirely blameless in this glitch. Surely, if a webinar is active, someone should be speaking. GoToWebinar is very good about warning the presenter when they have disabled screen sharing; e.g., by changing the focus to an application other than the application being shared. Why not have a red warning that comes up saying, “The webinar is in progress, but no audio is currently detected”? Obviously, some pauses, say for a few seconds, are not a problem, but in this case the audio was down for a total of four minutes. Also, depending on the way in which the failure of the microphone manifested itself to the GoToWebinar software–e.g., did the selected and active audio device abruptly disappear from the list of available audio devices?–perhaps GoToWebinar could have put up a warning that the active audio device has become unavaiable. I’m not sure what, but I know I could have used a much more urgent heads-up than the fairly passive indicator that GoToWebinar gave me.
In general, I have been very pleased with GoToWebinar and GoToMeeting–and yes, I have used the major competitors–but this failure to warn the presenter when the audio stops is a signficant usability/ error handling bug, in my opinion. I’d be much less inclined to recommend GoToWebinar as a webinar hosting tool now, after having this experience. If anyone from Citrix is reading, I’d be happy to discuss this with you. Same for you guys from Microsoft, regarding my assertion about the reason for the mike failure.
For those of you who were victims of this glitch and spent four minutes listening to dead air, you’ll be receiving a discount code applicable to any product or service in our store. Other than that little incident, I enjoyed the webinar and everyone’s great participation. The recorded webinar (of the evening presentation, that went without a hitch) will be posted in the next few days.
Tags: software reliability, software usability
Rex Black is President of RBCS (
