I was wondering why directsound was not implemented using openal. As direct3d is implemented on top of opengl. I see three major advantages : openAL is cross-platform, whereas alsa is linux-specific. openAL is (sometimes) hardware-accelerated. Wine would bring directsound hardware acceleration to windows vista :) See http://connect.creativelabs.com/openal/OpenAL%20Wiki/OpenAL%C2%AE%20and%20Wi... for manufacturers which bring hardware accelerated openal drivers...
Plus, wine would benefit of the system's openal configuration. No need to chosse between OSS and ALSA, the user would have done it through his openAL configuration.
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.
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.
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
Actually just spotted that some of the features are approved on the wish list, so it seems that OpenAL will include them in it's next specification.
On Thu, Oct 30, 2008 at 10:46:51AM +0000, Darragh Bailey wrote:
On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote:
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.
Couldn't tell if this is on the wish list, there appears to be some suggested enhancements for better buffer control, but I don't know enough to determine whether they actually match up.
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.
Requested: Item:2D panning/speaker level support Contributor: Creative Description: Approval Status: Approved
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.
Looks like this has been requested too: Item: Generic Effects Contributor: Creative Description: OpenAL could have a generic mechanism for enumerating and making use of the effects capabilities of the active audio device. Approval Status: Approved
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.
If all of the wish list gets added, it would appear the next specification of OpenAL would appear to me to go a long way to allowing wine to implement the Windows sound API's via that, rather than having to support various drivers.
If all of the wish list gets added, it would appear the next specification of OpenAL would appear to me to go a long way to allowing wine to implement the Windows sound API's via that, rather than having to support various drivers.
-- Darragh
Personally I think that even if OpenAL added the functionality we need that the user experience for most users still won't be good. Most users want to play lets say mp3's while they are gaming. This means that in order to work properly OpenAL under the hood again needs to use alsa+dmix or even worse pulseaudio. For that reason I'm not sure if going directly to OpenAL instead of going through wineoss/winealsa is any better.
Roderick
On Thursday 30 October 2008 06:05:20 am Roderick Colenbrander wrote:
Personally I think that even if OpenAL added the functionality we need that the user experience for most users still won't be good. Most users want to play lets say mp3's while they are gaming. This means that in order to work properly OpenAL under the hood again needs to use alsa+dmix or even worse pulseaudio. For that reason I'm not sure if going directly to OpenAL instead of going through wineoss/winealsa is any better.
winealsa/wineoss would have to do the same, really. With a proper DLL thunk, Win32 OpenAL apps can call directy to host OpenAL, which does have some improvements (namely talking to ALSA/OSS directly, up to 7.1 surround sound output (Creative's only does stereo for software mixing), using host configuration, etc).
DSound on top of OpenAL is a nice idea, IMO, it's just OpenAL's current short-comings prevent it from happening well enough.
On Thursday 30 October 2008 04:01:31 am Darragh Bailey wrote:
On Thu, Oct 30, 2008 at 10:46:51AM +0000, Darragh Bailey wrote:
On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote:
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.
Couldn't tell if this is on the wish list, there appears to be some suggested enhancements for better buffer control, but I don't know enough to determine whether they actually match up.
I've been thinking about this, and have some ideas. There's actually a few extensions I'm trying to get through Creative.. two I'm waiting on a response from, and two more I want to propose that would help DSound compatibility greatly.
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.
Requested: Item:2D panning/speaker level support Contributor: Creative Description: Approval Status: Approved
AFAIK, this is in EAX4. Though I can hope it means getting into the core API, I don't know.
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.
Looks like this has been requested too: Item: Generic Effects Contributor: Creative Description: OpenAL could have a generic mechanism for enumerating and making use of the effects capabilities of the active audio device. Approval Status: Approved
I think this is talking about sound effects, like low/hi-pass filters, reverb, etc. This can be done through the EAX and EFX extensions. Nothing about saying what's in hardware and what's in software.
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.
If all of the wish list gets added, it would appear the next specification of OpenAL would appear to me to go a long way to allowing wine to implement the Windows sound API's via that, rather than having to support various drivers.
I'm not sure what bearing the wish list has on the actual OpenAL API. I don't remember reading anywhere that anything approved will be put into the next core API revision. AFAIK, it could just mean they'll look into ways into adding it.. maybe via extensions.
On Thursday 30 October 2008 03:46:51 am Darragh Bailey wrote:
Just out of curiousity, have any of these limitations been raised with the OpenAL developers? Any of them in its future wish list?
I'm the developer of OpenAL Soft http://kcat.strangesoft.net/openal.html, which is becoming the implementation to use on Linux and other Unices (as the old Sample Implementation is deprecated/not maintained anymore). Though I'm not really hands-in with Creative or anything.. just a hobbyist developer making a Linux lib on his own time, who gives out his ideas.
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?
I would like to see DirectSound(3D) running properly on OpenAL, even if as a seperate project (eg. my DSound->OpenAL DLL project). It's not up to me whether such a thing would get into Wine or not, though.
Chris Robinson a écrit :
On Thursday 30 October 2008 03:46:51 am Darragh Bailey wrote:
Just out of curiousity, have any of these limitations been raised with the OpenAL developers? Any of them in its future wish list?
I'm the developer of OpenAL Soft http://kcat.strangesoft.net/openal.html, which is becoming the implementation to use on Linux and other Unices (as the old Sample Implementation is deprecated/not maintained anymore). Though I'm not really hands-in with Creative or anything.. just a hobbyist developer making a Linux lib on his own time, who gives out his ideas.
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?
I would like to see DirectSound(3D) running properly on OpenAL, even if as a seperate project (eg. my DSound->OpenAL DLL project). It's not up to me whether such a thing would get into Wine or not, though.
I think that your dsound->openAL wrapper could be used verbatim in wine, if wine provides an openal32.dll <-> native openal wrapper (as with opengl32).
By the way, did you try your dll with vista, which dropped dsound hardware acceleration ?
On Friday 31 October 2008 10:11:12 am you wrote:
I think that your dsound->openAL wrapper could be used verbatim in wine, if wine provides an openal32.dll <-> native openal wrapper (as with opengl32).
I have one of those, too, but it's not yet suitable for inclusion into Wine. In particular, I need to make wrapper functions for even all extension functions, which I haven't done yet (and unlike GL, there's no simple file I can parse to auto-generate such wrapper functions; but also unlike GL, there's not so many).
By the way, did you try your dll with vista, which dropped dsound hardware acceleration ?
I haven't, as I don't have Vista. I also don't think I have any cards that have a native OpenAL hardware driver. A problem with this is that a default OpenAL install will have an OpenAL->DSound wrapper as a fallback.. so if you have a DSound->OpenAL wrapper and a OpenAL->DSound wrapper at the same time, you obviously get some problems. ALchemy got around this by loading ct_oal.dll directly, bypassing the wrapper (at least in the free beta they had).
So it can work in Wine, with an OpenAL32 DLL thunk and a bit more work on both sides, but it working in Windows without locking down to specific drivers will be a bit more difficult.
-
Chris Robinson -
Darragh Bailey -
Jérôme Gardou -
Roderick Colenbrander