RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound

[Nick Burns]

Attached is my diff/patch for both an openal winmm driver and an 
openal32.dll thunk
   I would like to get these into wine -- please comment and stuff...

----Rant follows----
I seem to be making a habit of responding to myself... (this antihistamine 
is kicking in)

Sometimes in life you feel retarded -- at least this time I have an excuse 
(I am sick)

Anyhow -- I took all sorts of care to make sure that my OpenAL thunk was 
CDECL -- I even made sure that my spec file was perfect...
But, I for some reason (unknown to even the person who wrote this code -- 
me) I used WINAPI (stdcall) in all the actual impl of the OpenAL thunk

This explains why 'WINEDEBUG=relay' worked just fine -- but it failed in odd 
ways without the relay.

I fixed that in my thunk -- and all seems well

Tested with
   UT2004Demo (uses openal)
   hello_world.exe (al example code)
   playfile.exe (al example code)
On
   Mac Book Pro running Mac OSX 10.4.8 and tot wine

ut2004 notes -- in System (this can be done in the gui -- uncheck (yes 
uncheck -- the gui seems backwards) 'use system driver' under audio)
   mv DefOpenAL32.dll DefOpenAL32.dll_
   UT2004.ini -- change
       [ALAudio.ALAudioSubsystem]
       UseDefaultDriver=False
   then run
       WINEDEBUG=trace+openal wine UT2004.exe

Also I did play ut2004 -- menus and 2 bot matches sounded fine (though the 
mouse seems sluggish...)

(not tested in linux)

- Nick
> From: "Nick Burns" 
> To: [e-mail]
> Subject: Re: OpenAL and DirectSound -- openal32.dll first pass
> Date: Mon, 20 Nov 2006 20:43:05 -0800
>
> Sorry for the double post -- was unaware that '[e-mail]' was the 
> same thing...
>
> I was sick last night and could not sleep .: I wrote up an openal32.dll 
> thunk.
>
> I will be testing with ut2004/and the demos (hello_world and playfile) very 
> soon...
>
> I get sound with tracing but not without -- when it works ill submit a 
> patch...
> - Nick
> > From: "Nick Burns" 
> > To: [e-mail], [e-mail]
> > CC: [e-mail]
> > Subject: Re: OpenAL and DirectSound
> > Date: Mon, 20 Nov 2006 00:29:42 -0800
> >
> > I would really like to get my openal driver into wine...
> > But we should also have an openal32.dll
> >
> > For example -- on my Mac Book Pro running Mac OSX 10.4.8 and tot wine
> > If a windows application uses openal it will go from openal(windows) -> 
> > dsound HEL(wine) -> openal(osx)
> > This means the audio data has soo much fun traveling from api to api -- 
> > kinda like a code rollercoaster...
> >
> > Anyhow -- I will resubmit my openal patch -- maybe if I get some time I 
> > will try to make a thunk (or I could help ... or work more)...
> >
> > Also I would like help with my openal patch (get hw accel working for 
> > dsound and dsound3d)
> > - Nick
> > > From: Detlef Riekenberg 
> > > To: Stefan Dösinger 
> > > CC: [e-mail]
> > > Subject: Re: OpenAL and DirectSound
> > > Date: Fri, 17 Nov 2006 20:06:01 +0100
> > >
> > > On Fr, 2006-11-17 at 17:31 +0100, Stefan Dösinger wrote:
> > > > Just stumbled uppon some interesting thing about openal and
> > >
> > > DirectSound 3D on
> > > > vista: http://www.openal.org/openal_vista.html
> > > >
> > > > It sounds like openal will be the old way to get hw accelerated 3d
> > >
> > > sound on
> > > > vista, and creative is writing a dsound -> openal wrapper. Maybe it
> > >
> > > gets a
> > > > proper license so we can include it in wine :-)
> > > >
> > > > Maybe we should write an openal thunk for wine? Many games use openal,
> > >
> > > and it
> > > > seems that on wine openal uses directsound. That might work more
> > >
> > > better and
> > > > faster if we had a openal.dll which directly called linux openal :-)
> > > >
> > > > Just dropping the suggestions :-)
> > >
> > > There was something a while ago...
> > >
> > > Google-Result for "wineopenal":
> > > http://www.winehq.com/pipermail/wine-devel/2006-June/048273.html
> > >
> > > --
> > >
> > > By by ... Detlef

[Markus Amsler]

Nick Burns wrote:
> Attached is my diff/patch for both an openal winmm driver and an 
> openal32.dll thunk
>   I would like to get these into wine -- please comment and stuff...

+        wwi->al_device = p_alcCaptureOpenDevice(NULL, freq, format, 4 * 
wwi->waveFormat.Format.nSamplesPerSec * 
wwi->waveFormat.Format.wBitsPerSample / 8);
+//wwi->al_device = p_alcCaptureOpenDevice(NULL, 44100, format, 4 * 
wwi->waveFormat.Format.nSamplesPerSec * 
wwi->waveFormat.Format.wBitsPerSample / 8);
+        TRACE("wwi->al_device = %p\n", wwi->al_device);

You missed one C++ - comment :-)

Markus

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound

[Nick Burns]

Argh -- that lines not suppoed to be there hehe

Fixed locally
Will remove before submiting to patches...

Thanks for the find...

- Nick
> From: Markus Amsler 
> To: Nick Burns 
> CC: [e-mail]
> Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL 
> and	DirectSound
> Date: Tue, 21 Nov 2006 20:06:29 +0100
>
> Nick Burns wrote:
> > Attached is my diff/patch for both an openal winmm driver and an 
> > openal32.dll thunk
> >   I would like to get these into wine -- please comment and stuff...
> -
>    wwi->al_device = p_alcCaptureOpenDevice(NULL, freq, format, 4 * 
>
> wwi->waveFormat.Format.nSamplesPerSec * 
> wwi->waveFormat.Format.wBitsPerSample / 8);
> +//wwi->al_device = p_alcCaptureOpenDevice(NULL, 44100, format, 4 * 
> wwi->waveFormat.Format.nSamplesPerSec * 
> wwi->waveFormat.Format.wBitsPerSample / 8);
> -
>    TRACE("wwi->al_device = %p\n", wwi->al_device);
>
> You missed one C++ - comment :-)
>
> Markus

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound

[Stefan Dösinger]

Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
> Attached is my diff/patch for both an openal winmm driver and an
> openal32.dll thunk
>    I would like to get these into wine -- please comment and stuff...

Hey great, I will test it with Jedi Knight: Jedi Academy, which uses openal 
afaik :-)

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound

[Nick Burns]

Good luck
And may the Sound be with you...

- Nick
> From: Stefan Dösinger 
> To: [e-mail]
> Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: 
> OpenALand DirectSound
> Date: Wed, 22 Nov 2006 10:08:51 +0100
>
> Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
> > Attached is my diff/patch for both an openal winmm driver and an
> > openal32.dll thunk
> >    I would like to get these into wine -- please comment and stuff...
>
> Hey great, I will test it with Jedi Knight: Jedi Academy, which uses openal
> afaik :-)
> << attach4 >>
>

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound

[Stefan Dösinger]

Am Mittwoch 22 November 2006 11:44 schrieb Nick Burns:
> Good luck
> And may the Sound be with you...

Ok, after cleaning up the d3d mess in my tree a bit I gave your patch a try:

It applied fine, found AL/al.h after creating configure with autoconf, but 
compilation failed in dlls/openal:

openal.o: In function `wine_alutLoadWAVMemory':
/usr/src/wine/dlls/openal32/openal.c:327: undefined reference to 
`alutLoadWAVMemory'
openal.o: In function `wine_alutLoadWAVFile':
/usr/src/wine/dlls/openal32/openal.c:327: undefined reference to 
`alutLoadWAVFile'
openal.o: In function `wine_alutUnloadWAV':
/usr/src/wine/dlls/openal32/openal.c:326: undefined reference to 
`alutUnloadWAV'
openal.o: In function `wine_alutExit':
/usr/src/wine/dlls/openal32/openal.c:326: undefined reference to `alutExit'
openal.o: In function `wine_alutInit':
/usr/src/wine/dlls/openal32/openal.c:326: undefined reference to `alutInit'
collect2: ld returned 1 exit status
winegcc: gcc failed.

turned out that I needed the freealut package(gentoo). Stangely wine didn't 
link against that lib automatically, I had to specify -lalut manually.

Once the thing was compiled it worked perfectly with Jedi Academy :-) . Wine 
loaded openal32.dll builtin, and I had sound although I had no sound driver 
selected in winecfg, which shows that the whole api rollercoaster is 
bypassed. I had to configure the game to use openal first.

The sound appeared strange at first, but after using headphones instead of my 
broken notebook speakers it turned out that those were just stereo effects I 
never heard before :-) . I also used to wonder what that promiently 
marked "EAX Sound" option was that used to crash wine: Apparently exactly 
that openal option I enabled first in the config files :-)

/me joins the dark side of the sound

Great job!
Stefan

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound

[Stefan Dösinger]

Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
> Attached is my diff/patch for both an openal winmm driver and an
> openal32.dll thunk

Just a question: Are the different openal versions backward compatible, or do 
we have to ship a openal thunk for each openal version used by the games?

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound

[Nick Burns]

They are backwards compat -- and my thunk is backwards compat too..
(it should compile for openal1.0, 1.1, 1.X -- I have only tested Mac OSX 
10.4.8 OpenAL 1.1)

It is NOT efficent to be backwards compatible -- note my impl of AL_1_1, 
ALC_1_1, AL_EXTS, ALC_EXTS -- they all check for the existence of their 
functions ALL the time -- this is braindead and can be fixed with something 
similar to what we use for ogl -- the big func table -- and only update on 
context change -- maybe even cache per context function tables...

That being said -- the impls for AL_1_0, ALC_1_0, ALUT (not freealut) -- are 
as good as they can be. They are straight shots thru to the api (bouncing 
from CDECL(win32) -> ???(host???))

As it is (on this list) it should be correct -- barring oddities between 
deprecated ALUT functions...

- Nick
> From: Stefan Dösinger 
> To: [e-mail]
> Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: 
> OpenALand DirectSound
> Date: Wed, 22 Nov 2006 10:25:10 +0100
>
> Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
> > Attached is my diff/patch for both an openal winmm driver and an
> > openal32.dll thunk
>
> Just a question: Are the different openal versions backward compatible, or 
> do
> we have to ship a openal thunk for each openal version used by the games?
> << attach4 >>
>

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound

[Stefan Dösinger]

Hi,
> That being said -- the impls for AL_1_0, ALC_1_0, ALUT (not freealut) --
> are as good as they can be. They are straight shots thru to the api
> (bouncing
> > from CDECL(win32) -> ???(host???))

Afaik Linux libs are CDECL, if the win32 openal is CDECL too(not WINAPI / 
STDCALL), can we pass the Linux function pointers directly to the apps? 
Wasn't there some .so loading in the wine library loader some time ago?

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:OpenALand DirectSound

[Nick Burns]

Good point in some cases we can just let get proc address pipe the func ptr 
directly back to the app..

But..
On Mac OSX -- the stack must be 16 byte aligned (for and lib/sys call) -- 
this means we need to thunk for the stack on Max OSX -- If Linux or other 
plats have similar reqs then the thunking is required.

Personally I would rather have the layer as it gives us control on how 
windows talks with the system.

- Nick
> From: Stefan Dösinger 
> To: [e-mail]
> Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was 
> Re:OpenALand DirectSound
> Date: Wed, 22 Nov 2006 12:38:46 +0100
>
> Hi,
> > That being said -- the impls for AL_1_0, ALC_1_0, ALUT (not freealut) --
> > are as good as they can be. They are straight shots thru to the api
> > (bouncing
> > > from CDECL(win32) -> ???(host???))
>
> Afaik Linux libs are CDECL, if the win32 openal is CDECL too(not WINAPI /
> STDCALL), can we pass the Linux function pointers directly to the apps?
> Wasn't there some .so loading in the wine library loader some time ago?
> << attach4 >>
>

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:OpenALand DirectSound

[Stefan Dösinger]

Am Donnerstag 23 November 2006 01:16 schrieb Nick Burns:
> Good point in some cases we can just let get proc address pipe the func ptr
> directly back to the app..
>
> But..
> On Mac OSX -- the stack must be 16 byte aligned (for and lib/sys call) --
> this means we need to thunk for the stack on Max OSX -- If Linux or other
> plats have similar reqs then the thunking is required.
>
> Personally I would rather have the layer as it gives us control on how
> windows talks with the system.

Yeah, I guess modern CPUs make such calls cheap, thanks to all the little 
getters and setters they have to deal with thanks to object oriented 
programming

And we get traces this way