After STALKER: Clear Sky failed to generate viable sound output using the existing drivers (in GIT head as of a few days back), I started looking for solutions and stumbled over this thread: http://www.nabble.com/RFC:-OpenAL-Winmm-driver-and-OpenAL32.dll-thunk-was-Re...
I brought the patch up to speed with current Wine to the best of my knowledge and pasted it here: http://pastebin.com/f2a559a22
It appears to make sound work flawlessly in at least one OpenAL-based game, and I suspect there may be more.
In case this driver adds too much of a support/code overhead, would it be possible to add it as a band-aid, until the problem that prevents the other back-ends from working with Clear Sky is fixed?
Thanks for your comments.
--feep
PS: No I'm not running Pulseaudio :)
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
After STALKER: Clear Sky failed to generate viable sound output using the existing drivers (in GIT head as of a few days back), I started looking for solutions and stumbled over this thread: http://www.nabble.com/RFC:-OpenAL-Winmm-driver-and-OpenAL32.dll-thunk-was-Re...
I brought the patch up to speed with current Wine to the best of my knowledge and pasted it here: http://pastebin.com/f2a559a22
It appears to make sound work flawlessly in at least one OpenAL-based game, and I suspect there may be more.
In case this driver adds too much of a support/code overhead, would it be possible to add it as a band-aid, until the problem that prevents the other back-ends from working with Clear Sky is fixed?
Thanks for your comments.
--feep
PS: No I'm not running Pulseaudio :)
There is nothing really wrong with a openal32 -> libopenal wrapper but a winmm openal driver isn't that useful. The reason is that since openal in general just uses oss and alsa (yes on creative cards there is a decent backend) which illustrates that our current oss/alsa plugins can offer similar performance. It is just that various parts aren't very optimal at the moment and adding a winmm openal driver is a workaround and leads to another half baked solution (like esd, jack, nas ..).
Roderick
The problem with the openal32.dll -> libopenal.so wrapper was that it broke some games, and we never debugged why. If anyone wants to continue this development I think this wrapper library is something that would be highly welcome.
As for the winmm driver, Roderick pretty much said it. We don't need another half baked sound backend, the effort should instead be put into making sure we have one properly working one for each platform(Alsa for Linux, coreaudio on the mac, not sure about *BSD and Solaris)
On Mon, Jan 19, 2009 at 11:33 AM, Stefan Dösinger stefan@codeweavers.com wrote:
The problem with the openal32.dll -> libopenal.so wrapper was that it broke some games, and we never debugged why. If anyone wants to continue this development I think this wrapper library is something that would be highly welcome.
As for the winmm driver, Roderick pretty much said it. We don't need another half baked sound backend, the effort should instead be put into making sure we have one properly working one for each platform(Alsa for Linux, coreaudio on the mac, not sure about *BSD and Solaris)
Solaris was libaudioauio, but they're moving toward Boomer, which is supposed to be OSS compatible.
*BSD, I'm not sure off, I'll look around.
On Monday 19 January 2009 9:33:26 am Stefan Dösinger wrote:
The problem with the openal32.dll -> libopenal.so wrapper was that it broke some games, and we never debugged why. If anyone wants to continue this development I think this wrapper library is something that would be highly welcome.
In Linux, I'd imagine it's because the old Linux lib wasn't coded very well. However, newer versions of OpenAL on Linux are based off the same code the Windows version is derived from (the original Windows version was LGPL, then was closed up; the recent Linux versions were ported and enhanced from the LGPL code).
I don't really know how well the OSX version of OpenAL works for this purpose, though.
As for the winmm driver, Roderick pretty much said it. We don't need another half baked sound backend, the effort should instead be put into making sure we have one properly working one for each platform(Alsa for Linux, coreaudio on the mac, not sure about *BSD and Solaris)
Yeah, a WinMM driver pretty much won't work well. A better idea would be wrapping DirectSound around OpenAL, and I have code that does that; but it's not perfect yet, and it would have to be ported to C from C++ for any hope of inclusion in Wine (it's currently a real native DLL, cross-compiled with MinGW, depending on the aforementioned OpenAL DLL thunk).
IIRC, most of the problems surrounding the DLL thunk were two things:
1) The original patches used a lot of macros to do the function thunks. Alexandre didn't like that and wanted it expanded. This part I've done, though the thunks are missing TRACEs.
2) The functions returned by al[c]GetProcAddress also need to be wrapped. Although the Linux and Windows version use the same calling convention (cdecl), AJ says this can break on OSX. To do this, we'll likely need some kind of script like opengl32 uses (luckilly not too many extensions provide functions, so the needed wrappers will be minimal compared to opengl; but I've been lazy in setting that up).
There's probably some other things that need to be done, but those two are the big ones I remember. I've attached a patch with the latest version I have.. it's a little broken on OSX currently because it's not checking for the OpenAL framework, and I'm not sure how to do that properly.
-
Austin English -
Chris Robinson -
FeepingCreature -
Roderick Colenbrander -
Stefan Dösinger