[Openal-devel] Creative Labs and OpenAL

[Ed Phillips]

Hi,

On Thu, 23 Aug 2007, Daniel PEACOCK wrote:

>> Why not move the IP into ct_oal.dll instead of putting it in 
>> wrap_oal.dll? That way, the DirectSound3D, software mixer and whatever 
>> else could be updated in SVN, while the rest would be protected in the 
>> proprietary binary.
>
> The ct_oal.dll is different - it communicates directly with the 
> soundcard drivers (by-passing DirectSound, DirectSound3D, WDM, KMixer, 
> etc ...).  This is the reason that this component continues to work in 
> Windows Vista even though Microsoft removed the DirectSound Hardware 
> Abstraction Layer (HAL).  The ct_oal.dll only works on certain 
> soundcards - e.g Audigy and X-Fi hardware based cards.
>
>> Okay.  What about older card that don't have drivers that come with a
>> "ct_oal.dll", like SBLive! cards... can the benefit from the Creative
>> wrap_oal.dll to acheive hardware spatialization via the DirectSound3D
>> mechanism?
>
> The wrap_oal.dll's "Generic Hardware" device will work on all soundcards 
> that support 'hardware' DirectSound3D (e.g all Audigy cards, all X-Fi 
> cards, and pretty much all soundcards and motherboard audio devices). 
> (Not on Windows Vista though, due to the removal of the HAL.  The 
> 'Generic Software' device will work though.)

So a game that uses OpenAL (OpenAL-Windows), which presents the DS3D 
("Generic Hardware") device as the default, will fail to work on Vista, 
I'm guessing. Does the new Creative "OpenAL SDK" wrap_oal.dll or 
openal32.dll deal with this known problem or is the app/game expected to 
deal with it?

>> Has the DirectSound3D mechanism changed much between what's in the 
>> OpenAL-Windows tree and what's in the new "OpenAL SDK" from Creative? 
>> I think OpenAL would benefit greatly if that code were maintained and 
>> updated in SVN... assuming that it's out of sync now.
>
> There have been bug-fixes, optimizations and new features (most notably 
> the EFX Extension).  But as I mentioned a lot of the code contains IP 
> that we can't open-source.

It sounded like the IP is not the same code as the DS3D bits (which should 
be pretty generic I'd guess), but rather, the EFX extension code, the 
reverb code, etc.

Given what you said about DS3D not working on Vista due to the missing DS 
HAL, it would seem the router or the game needs to know to choose a 
"native" OpenAL device on Vista (if available) or fall back to "Generic 
Software" because "Generic Hardware", although presented by wrap_oal.dll, 
won't really work on Vista.  Conversely on XP, the normal wrap_oal.dll 
behavior of defaulting to "Generic Hardware" works for most sound cards, 
so there's no need to fall back to "Generic Software" unless there's some 
glitch in the drivers that the user encounters and they need to manually 
change to software mixing.  On XP, the router might see a "native" device, 
but won't normally use it if wrap_oal.dll is available (i.e. it's the only 
implementation on the system) and the game/app either opens the NULL 
device or the actual device name implemented in the DLL.

Does the string name of the device (ALC_DEVICE_SPECIFIER I'm guessing) 
presented by ct_oal.dll et. al. show up as the literal string "native", or 
some kind of product name like you'd see in the audio control panel? 
(I've never actually used a ct_oal.dll or other native driver yet - since 
my SBLive! 24-bit doesn't have one, and I don't think my old "SBLive! 
Value Edition" card has one either even though it's Emu10k1 based and 
actually does hardware 3D sound).

If there is more than one sound card in the system, what will the OpenAL 
router see and how could the user or game select between them?  For 
example, if I have an Audigy 4 PCI card, but also have my on-board AC97 
sound enabled too...

Thanks,

 	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer IV, Network and Systems Services