This also applies to derived titles like UT2K4, ROO4145 and KF.
We can see from the sources of the menus how the audio modes maps to cvars:
- Safe mode: bCompat=1, b3DSound=0, bEAX=0
- (Software) 3D Audio: bCompat=0, b3DSound=0, bEAX=0
- Hardware 3D Audio: bCompat=0, b3DSound=1, bEAX=0
- Hardware 3D Audio + EAX: bCompat=0, b3DSound=1, bEAX=1
And from the leaked UT2004 code we in turn know how they map with the ALAudio alcOpenDevice call:
Device = UseMMSYSTEM ? "MMSYSTEM" : Use3DSound ? "DirectSound3D" : "DirectSound";
Compatibility mode is just the first variable (using WinMM/WaveOut instead of DS), while the EAX one guards the initialization of the subsequent alEAXSet (which is then what enables everything else EAX-related if successful). Note that just setting bEAX will also force instate the b3DSound variable.
The directsound references also aren't an oversight.. before version 1.1 was released in 2006, openal wasn't a first party api with direct hardware access but just a cross-platform glue/abstraction.
Last but not least (after cutting some logging code and replacing some reference) this is the logic behind the system driver option:
if( !UseDefaultDriver ) DLLHandle = appGetDllHandle( "OpenAL32.dll" ); if( !DLLHandle ) DLLHandle = appGetDllHandle( "DefOpenAL32.dll" );