§ ¶DirectSound Renderer latency woes

I'm tweaking my laptop-as-a-TV setup again, and am running into problems with latency in the DirectShow filter graph.

The video path I cobbled together a while ago, and works as follows: I have preview acceleration mode activated VirtualDub and set to interlaced fields / even field first, which then pushes the video through a Direct3D pixel shader that does adaptive deinterlacing and upsampling to field rate with a little bit of bicubic filtering and gamma adjustment thrown in. That works surprisingly well, with good latency and a decent image. The problem is the audio, which initially starts out fine but slowly accumulates a lot of latency over time. I've spent a while fiddling with the filter graph clock and perusing the various (many) interfaces, and have determined the following:

• Rate matching by data rate is active on the audio renderer.
• The capture filter is sending 40ms audio buffers, and doesn't seem to respond to IAMBufferNegotiation requests to change it. Therefore, that's 40ms of audio latency I can't get rid of.
• The DirectSound buffer size is about one second.
• The buffer level reported through IAMAudioRendererStats very slowly rises over time, from about 4% to 90%.
• Neither SyncUsingStreamOffset() + SetMaxGraphLatency() nor SetErrorTolerance() appear to help.

I had this same problem with my Adaptec GameBridge, and now it's happening with my ATI capture device, so I don't think it's capture driver specific.

It looks like the current problem is that the DirectSound Renderer is intent upon slowly filling up its one second buffer over time, even though that is a huge amount of latency to add to a live stream. For a live TV stream, that usually isn't a problem, as the audio and video just need to have the same amount of delay to be in sync. However, since I'm trying to play Ar Tonelico, any delay on either the audio or video stream results in a delay relative to the controller inputs, and I really don't want that amount of latency anywhere in the system. It's a bit frustrating that the audio system runs well at first but gradually slews to unusability until I reset the filter graph again.

Does anyone have any experience with this problem or tips as to how to solve it? I really don't want to have to write my own audio renderer, but I'm beginning to think that might be the best solution.

§ ¶The requested length is too int

The type long is problematic in C, because its exact type is not defined, and practically it can be either 32-bit or 64-bit on common platforms. Sometimes people will do a mass search-and-replace to change all variables declared as long to int in order to fix portability issues. If you do this, you need to make sure you check the diffs or you will end up publishing something nonsensical:

This function returns status values as follows:

    CBS_INVARG  requested file name length is too int

§ ¶The Windows registry vs. INI files

I've been asked a few times over the years why I use the Windows registry to store settings instead of INI files. The main answer is that it's a cleaner and easier to use interface for storing settings. The registry certainly has its faults, but it has a number of advantages as well:

• It cooperates with user profiles. The registry contains portions that are both per-machine (HKEY_LOCAL_MACHINE) and per-user (HKEY_CURRENT_USER). Data put in HKCU automatically works with multiple users, roaming profiles, profile backup/restore, etc.
• It has a key/value interface that does not require parsing. You can put arbitrary data into the registry without escaping.
• It already has a GUI tool for inspection and tweaking (regedit).
• The registry store is managed by the kernel. If your application hangs or crashes, changes to the registry are still committed. If the system dies, it's the responsibility of Windows to ensure that the registry is valid.
• Access to the registry is thread and multiple instance safe. Multiple threads and multiple processes can simultaneously access the same registry value and updates are atomic.

IMO, the last one is the biggest advantage. One of the problems with using INI files is that you have conflicts on the INI file if multiple instances of the same program are run from the same location; this is made more difficult by inability to queue conflicting file opens or atomically commit partial updates into the file. Using the registry means that you can exchange data between multiple running instances. For instance, if a dialog commits last used values, the same dialog in another instance can pick up the same values as the defaults. I'm slowly moving toward trying to have more data stored and retrieved "just-in-time" in this manner; it reduces the cases where settings unexpectedly revert, either because the program died before it could save settings on exit, or one instance exited and committed all of its settings regardless of which ones changed.

As for arguments against the registry, one is that it stores settings in one big binary blob in the user profile that's hard to manage and backup. That's definitely true, and it's unfortunate that Microsoft didn't provide a good way to isolate a branch of the registry in a separate file. You can use RegLoadKey() to do this to some extent, but it's unfortunately a global operation instead of a process-local operation and requires backup/restore privileges. The second is that you can manually tweak an INI file in a text editor. I'm not sure I buy that argument as much, as it's difficult to programmatically commit settings back to an INI file in a way that keeps them readable, particularly if you're persisting data structures. It's a bit like XML used as a serialization format -- I wouldn't call it human readable so much as human parseable.

There is one more argument against the registry and for INI files: portable operation. This is where settings are stored in a file next to the executable so both can be moved together. This does hold plenty of water, I have to admit. As a test, I added some experimental code into an Altirra test release that allows registry operations to be shunted to a virtual registry, which is then loaded from and stored to an INI file. The INI file looks a bit funny, but the advantage of doing it this way is that the program can run both in registry and in portable INI file mode. This seems to be working out pretty well, so I'm planning on back-porting that code to VirtualDub.