The work is split into a couple of portions - a portion which runs in a DSP at the full audio sampling rate, and a portion which runs at a lower rate and tracks the object's trajectory (this being done by the ARM, in the 3DO system).
We tested the first 3DO-native implementation of the method using a simple little game program. It showed a bunch of bubbles floating around in a room. Music was being played (I _still_ can't get that damned little tune out of my head) by one of the bubbles. The goal was to zap whichever bubble was playing the music - the game would cheer, and then the music would jump over to another bubble. Most people were able to do this with their eyes closed - they'd put on headphones, navigate around the room "by ear", and zap the correct bubble when it was positioned directly in front of them. Lots of fun... I was gratified at how well it worked.
I'm not sure whether any of today's 3DO titles are using the full 3D-sound method. We weren't able to discuss it with developers in any great detail during the patent-filing process, and haven't really urged developers to use it. This may very well change now that the patent has been awarded and the method is part of the public record.
The other sound-mapping capabilities of the 3DO sound architecture are related to the 3D-sound patent, but only somewhat indirectly. We designed the 3DO's audio DSP to run the 3D-sound method efficiently, and (fortunately) ended up with a DSP which has a very great deal of flexibility and power. It's easily capable of handling other sound-mapping and surround-sound algorithms such as Dolby Surround, as well as multi-voice score playing and sound-effects generation. These other capabilities can be used in addition to, or in place of the 3D-sound method.
Phil Burk took on the job of developing a high-level "audio folio" which would make this flexibility available to software designers, and he's done a really bang-up job of it. Developers can actually design their own "instruments" via a graphic user interface (rather like patching together building blocks in an analog or digital synthesizer), hit a button to "compile" their instrument into DSP assembler code, and then test it in real time. It's pretty neat...
michel.buffa@cmu.edu