RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound
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" <adger44(a)hotmail.com> To: wine-devel(a)winehq.org 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 'wine.dev(a)web.de' 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" <adger44(a)hotmail.com> To: wine.dev(a)web.de, stefandoesinger(a)gmx.at CC: wine-devel(a)winehq.org 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 <wine.dev(a)web.de> To: Stefan Dösinger <stefandoesinger(a)gmx.at> CC: wine-devel(a)winehq.org 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
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
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 <markus.amsler(a)oribi.org>
>To: Nick Burns <adger44(a)hotmail.com>
>CC: wine-devel(a)winehq.org
>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
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 :-)
Good luck And may the Sound be with you... - Nick
From: Stefan Dösinger <stefandoesinger(a)gmx.at> To: wine-devel(a)winehq.org 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 >>
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
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?
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 <stefandoesinger(a)gmx.at> To: wine-devel(a)winehq.org 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 >>
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?
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 <stefandoesinger(a)gmx.at> To: wine-devel(a)winehq.org 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 >>
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
participants (3)
-
Markus Amsler -
Nick Burns -
Stefan Dösinger