DIrectSound on top of openAL ?

[Roderick Colenbrander]

> On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote:
> > 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.
> 
> 
> Just out of curiousity, have any of these limitations been raised with the
> OpenAL developers? Any of them in its future wish list?
> 
> If OpenAL was updated with the next release 1.2+ to support the type of
> access that wine needs to support the windows sound API's on linux,
> would it make it easier that supporting multiple sound drivers?
> 
> 1.0 was released 2000, 1.1 in 2005, so it's probably due a new release
> in the next year/two, so it might be possible to add some feature
> requests that would make implementing DirectSound on top of OpenAL
> visible in the future.
> 
> -- 
> Darragh
> 
> "Nothing is foolproof to a sufficiently talented fool."

The design philosophy behind OpenAL and OpenGL is to hide hardware details from the designer.  For instance the libraries hide things like buffer sizes or the amount of video memory. DirectX APIs like Directsound and DirectDraw/Direct3D provide you will all sorts of hardware info which the designers of OpenAL and OpenGL should be hidden. The reasoning is that if you expose such hardware details that you end up with hardware specific codepaths and not with generic solutions which are also more future proof.

Roderick
-- 
GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger.
http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/index.html