Re: DIrectSound on top of openAL ?

[Jérôme Gardou]

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 , 
> 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 ?

Re: DIrectSound on top of openAL ?

[Chris Robinson]

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.

Re: DIrectSound on top of openAL ?

[Chris Robinson]

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 , 
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.

Re: DIrectSound on top of openAL ?

[Chris Robinson]

On Thursday 30 October 2008 04:01:31 am Darragh Bailey wrote:
> On Thu, Oct 30, 2008 at 10:46:51AM +, 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.

Re: DIrectSound on top of openAL ?

[Chris Robinson]

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.

Re: DIrectSound on top of openAL ?

[Roderick Colenbrander]

> 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
-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

Re: DIrectSound on top of openAL ?

[Darragh Bailey]

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 +, 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.

-- 
Darragh

"Nothing is foolproof to a sufficiently talented fool."

Re: 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

Re: DIrectSound on top of openAL ?

[Darragh Bailey]

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."

Re: DIrectSound on top of openAL ?

[Chris Robinson]

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.

DIrectSound on top of openAL ?

[Jérôme Gardou]

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%20Windows%20Vista%E2%84%A2.aspx
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.