¶Audio preview issues with ATI Theater HD 750 USB
I picked up an ATI Theater HD 750 USB capture device recently to add to my arsenal. As it is, I have far too many capture devices as it is, but about half of my collection is PCI, and now that I'm laptop-based that's rather inconvenient. I have two other USB capture devices, a Plextor and a GameBridge. The problem with the Plextor is that it produces a soft image and produces compressed video, so it has significant latency, about 300ms. It's also a bit big. The GameBridge is much smaller and produces straight UYVY -- perfectly fine for what I do -- but as it turns out, it will not sync to an Atari 800XL, whose video signal is too far out of spec. I was pleased to discover that the ATI device also outputs uncompressed data and does sync to the Atari, although the color decoding is kind of crappy... but that's a story for another time.
Unfortunately, I also discovered to my annoyance that the 750 USB has a problem with VirtualDub: it stutters horribly when "enable audio playback" is set. That option allows you to hear the output of capture devices that aren't sound cards in Windows, but the unofficial story is that it's the "emulate a TV set" option. I always hate debugging these issues because they always turn out to be issues where something isn't getting along with the DirectShow capture graph, which means doing all sorts of arcane incantations to try to fix it. After playing around a bit with Microsoft GraphEdit and with the cap_dshow.cpp module, I figured out that it was a problem with the filter graph clock. The filter graph clock is an entity, either in the filter graph or external, whose job is to supply a uniform timebase for all data that moves through the filter graph. This then allows the renderers that are displaying the video and playing the audio to all work off of the same timestamps and to also schedule their output to the same clock. For instance, video players typically have the DirectSound Renderer providing the clock, with the video renderer syncing to audio playback. This is also the configuration that VirtualDub normally chooses when the audio playback option is on. It turns out that the 750 doesn't like that configuration and has oscillation problems with it. The usual way to attack these problems is with the "disable timestamps for preview" option in Capture > Timing in recent versions of VirtualDub; this normally solves the problem by killing the timestamps and causing everything to play immediately as it arrives. Well, that's even worse, as the ATI capture filter doesn't even want to start in that case.
What does work, though, is using the system clock (CLSID_SystemClock). The bad part about this is why VirtualDub has its current behavior. I dug up the P4 revision history for that module, and it turns out the reason I wrote it this way is that I couldn't get the capture driver for the SAA713x to work with audio playback without using the audio renderer's clock. In particular, the system clock specifically did not work with that card. This means that the only way I can make this work across the board is to make the filter graph clock option three-way so the working clock can be manually chosen. Yuck. I hate doing this since it's just throwing the problem to the user. Heck, I wrote the program and I didn't know the answer either -- I just tried all of the options in code until I found one that worked. Unfortunately, this seems par for the course with DirectShow, which I've found to be one of the flakiest parts of Windows. I've described my disdain for this API before, and this is further reinforcement. It's bad enough that the API is complex, but too many of the third-party filters have antisocial behavior or hideous bugs, especially capture drivers.
Anyway, expect a fix for this issue to be available in a future version of VirtualDub. I'm thinking it'll probably be in the next experimental version, as I'm pretty risk averse at the moment to pushing things into the stable branch, and changes to DirectShow graph building code rank pretty high on my risk chart. If you have a device like this and want to try a hacked up test release, though, let me know -- I could always use some testing.