§ ¶Live audio playback

My latency woe research continues, this time on how to handle playback. I've managed to write a new basic audio renderer and hook it into the DirectShow graph, but the next issue now is how to handle playback. When playing stored audio/video data, you can read the source at variable rate as necessary, so playback timing is simple: minimize the difference between the audio and video timing. In other words, the user can't really tell that you're buffering two full seconds of audio if the video is also delayed by the same amount. Where this does matter is in seek latency, because then the decoder needs to re-fill that delay before you can restart playback, but even then doing soft start or just having a fast decoder can do the trick.

However, live input -- or specifically in this case, interactive live input -- is a tougher problem. In this case the clock already starts ticking the moment the user hits a button, and therefore you're already late by the time you receive audio. This means that minimizing latency in the entire pipeline is absolutely critical. Unfortunately, as I mentioned before, the recording device I'm using sends 40ms packets, so already by the time I receive the first byte I'm already that much behind and I don't really need another 100ms of latency on the output. This means that in the playback code, the problems are:

§ ¶VirtualDub 1.9.10 released

New stable release is out -- as usual, no new features, but a handful of bug fixes.

The first important bug fix is that the dwInitialFrames field is now unilaterally cleared when writing AVI files. In some cases, VirtualDub was passing this value through from source files, which caused compatibility problems as some players didn't like non-zero values. Like many header fields, this one is also underdocumented in Microsoft docs, is misinterpreted by various players, and isn't supposed to have any effect on audio sync or sample timing. Some users were encountering issues with this value being left non-zero, though, so the program now always zeroes it.

The second fix is one that was lurking for a while, but didn't appear until some recent feature additions, and was the issue that prompted this release. There was a bug in the thread tracking code that caused a handle leak for all unnamed threads. Most of VirtualDub's threads are named, as you'll discover if you run it under a debugger, but it turns out that the threads used for multithreaded compression weren't. This manifested as an occasional Invalid Handle exception when running a lot of jobs with threaded compression enabled. That's now fixed, so you should now see better stability on such operations.

There has been some confusion about the difference between test/dev/stable releases, and why the dev-test releases have features that don't appear in the stable releases. Some time ago, I switched over to a branched development environment, where the stable releases use a different code line than the dev tree. The reason for this is that it allows me to push only selected fixes into the stable branch and produce clean releases. In the past, I had a couple of accidents where temporary testing hacks ended up getting pushed out with fixes, which then forced me to do an oops-re-release. I hate doing that, so now I use multiple branches to segregate the work. The test versions are quick builds that I do on either line so that users encountering an issue or wanting a feature can take a look at the latest bits; this allows for much faster iteration, but the downside is that those are literally just the latest bits off the code line and about the only guarantee is that it compiles, which is why I don't publish them more formally. These versions are all tagged with -prerelease on startup, so you'll know if you're running one of those.

Changes in this version:

§ ¶Altirra 1.7 released

Things have eased up and I've gotten a little bit more time lately for hobbies, so it's time to start flushing out the release backlog. We'll start with Altirra, since it's the easier one to release and I'm feeling lazy today.

The new release is version 1.7. New features include flash cartridge and IDE emulation, portable mode, fast boot, video recording, hard disk burst I/O, and secondary monitor display acceleration. Bug fixes include debugger stability improvements, CPU undocumented instruction fixes, and improved compatibility for the built-in HLE kernel. Since it's been about four months since the last release, this version has gotten extra testing, and special thanks to Mclane and Breaker for continually testing new releases (and contributing to the epic comment thread on the last post).

It's safe to say that I never thought I'd get this far, and now that I know how much is involved, I'm not likely to try writing another emulator. Well, unless I get another nostalgia kick, and truth be told, the Heathkit H-89 and TRS-80 Model 4 are not nearly as interesting machines. The Apple II doesn't have much in the way of interesting hardware. The C64 never interested me as much, and I hated that butt-slow 1541 disk drive with a passion. (No, I didn't have the Epyx fast load cartridge. Yes, I was bitter.) There's the TI-99/4A, but the only good game I had was Parsec, and TI BASIC made the 1541 look fast. Oh, there's the Amiga....

...

Hmm.

No, I'd better not.

Anyway, if you're an Atari 8-bit fan, please enjoy the new version.