DIrectSound on top of openAL ?

Chris Robinson chris.kcat at gmail.com
Tue Oct 28 16:16:12 CDT 2008


On Sunday 26 October 2008 06:06:07 am Jérôme Gardou wrote:
> I was wondering why directsound was not implemented using openal. As
> direct3d is implemented on top of opengl.

It's not very easy to get DirectSound working on top of OpenAL. I actually 
made a DSound->OpenAL wrapper (as a native C++ Win32 DLL, so it can't go into 
Wine as-is even if I wanted it to), but it's none too stable. Some apps work, 
others don't. Some work better than others.

The biggest problem is updating the sound buffer in real-time (DSound lets you 
lock a sound buffer and modify it while it's playing; OpenAL only lets you 
rebuffer the whole buffer, while it's not attached to any source). I get 
around this by spawning a real-time thread which queues small chunks "just in 
time" to keep the buffer playing, but this is a hack at best.. there's no way 
to know how much you need to buffer ahead so OpenAL doesn't run out during an 
update, some apps are more sensitive to a large write-ahead, and real-time 
threads aren't really available in Wine (meaning even larger sections would 
need to be queued to be able to update in time). The problem is compounded 
when you consider multiple DSound buffers can share the same data buffer.

Another problem is the lack of panning. OpenAL has no controls for panning a 
2D sound. At most you can move the sound left and right to simulate panning 
(for mono sources; stereo is out of luck), but the actual algorithms are 
implementation dependant and thus would not produce consistant results.

Additionally, OpenAL hides a lot of the hardware vs. software caps. OpenAL 
doesn't tell you if you're using hardware or software, while DSound would 
tell you. Of course you can always lie and say you have hardware (which I 
found was needed to get some games to even attempt to use DSound3D), but it's 
not entirely proper.



More information about the wine-devel mailing list