Pretty much every third party sound library for games implements 3D audio support (commercial ones probably for the last 10 years or more) but in order to use more than just the spatial sound source location/user facing vector requires inputting the material types/locations/sizes/audio properties for everything in the game world (to calculate audio propagation loss/occlusion) and using a certain percentage of cycles per frame to this - not everyone chooses to dedicate this much work to audio or has the extra CPU cycles to do this after graphics/physics. Also they have to be able to support simulating the head transfer function via speaker (many possible configurations) or headphone so that's doubled or tripled the amount of QA for audio sfx instead of relying on a VR headset for a standard setup for VR, in addition to possibly adding some sort of customization for each individuals head transfer function. If your games don't really use it, it's because the developer didn't have the time/money/CPU budget for it because it probably wasn't a key feature.
Not sure what is different about Google's offering in VR space versus tradtional game audio engines here.
yes, HRTF, just typing hastily. If one enables HRTF support for instance, as this quick googleing finds support in an eight year old query on FMOD,
http://www.fmod.org/questions/question/forum-29423/
one needs to support/not support/test all the cases, with the HRTF enabled/disabled, user deciding to use headphones/speakers with whatever configuration they have. Maybe one will decide it sounds better with HRTF on with speakers or decide that's not a good idea and not allow it or not even support HRTF. It's up to whomever made the game to determine how to support whatever the user decides to use. So in the general case of games not just VR, one might have a console version and a PC version and may need to support headphones/2 speakers/multiple speaker set ups and enabling/disabling features on demand per configuration. So back to the original query this requires signficantly more QA/testing than supporting just HRTF with VR headphones.
More than impossible, it's the wrong thing. Speakers in a room don't move with your head when you turn it. By the time the sound gets to your ears, it's already had an HRTF applied - the natural one. The thing to go for there is wavefield synthesis, not any flavor of HRTF.
> I don't think OpenAL simulates some of the more complex phenomena having to do with how sound interacts with your body and ears?
It does. This blog post [0] seems to be a nice reference. What you want is called "head-related transfer function". (There are tons of papers on HRTF)
One can even turn it on for any game that use openal, even old ones. You can go download The Dark Mod now and play it with HRTF [1].
Note: am not an expert
What openal doesn't do, while this google thing does, is reverb (reflection of waves, echo). One way to do reverb is.. well simply raytrace it. Just send out a bunch of rays from the source, probably do some filtering of the results, and apply to the audio. Another way is to take a real room that you are "porting" to digital, ping somewhere in it (play the impulse response of an ideal 20kHz low pass filter, aka the sync function), then measure somewhere else. Then repeat in a.. grid or something. What you get is a bunch of filters (num_points if there is a single static "listener", or num_points^2 if there are more and or moving; as it is source->destination dependent). This can also be done by shooting rays in an arbitrary digital space, but i wanted people to imagine a room and waves going around in it. AFAIK this is how the valve bought software works.
Another thing is diffraction[2]... that idk if either gugl or volvo do. Calculate it with voxel grids then add to refraction ? Any renderers do proper Rayleigh scattering ?
Not sure what is different about Google's offering in VR space versus tradtional game audio engines here.