NewsForumsCodeLogsGallerySpecsSearch

OpenAL grief

BlitzMax Forums/BlitzMax Programming/OpenAL grief

Imphenzia(Posted 2009) [#1]
This has been mentioned in the forum before but I run into problems with it unfortunately. I've copied OpenAL32.dll (and wrap_oal.dll just in case) as specified in the other posts but the code below does not show me the OpenAL driver?



I have saved the DLL:s in the same folder as the compiled file above and the result is:


If I install the distributable OpenAL I see it in the list, but I just want to wrap it in the game - additional installs is an absolute nono for me :)

(I'm running Windows 7 x64 by the way)

any thoughts?


theHand(Posted 2009) [#2]
Only to provide support for both OpenAL and FreeAudio (falling back to FreeAudio if OpenAL is not installed on the user's computer).
Sorry. :(


Imphenzia(Posted 2009) [#3]
Ouch, is it that bad? =) Thanks for the reply though!


Brucey(Posted 2009) [#4]
That's interesting, because all it does is this :
	openAL=LoadLibrary( "OpenAL32.dll" );

which should work if the dll is in the same folder as the executable.


markcw(Posted 2009) [#5]
Try it in release mode.


GfK(Posted 2009) [#6]
Ouch, is it that bad?
No - OpenAL works.

Are you absolutely sure you've got the DLLs in the right place? Because what you're getting is a classic symptom of the DLL not being found.

Or do you have some funky Frameworking/Importing going on?


Imphenzia(Posted 2009) [#7]
No framework or import and I've also tried this:


and my output is this:


If I install OpenAL it will work, but if I copy the DLL from windows\system32 to my folder where the compiled file is and then uninstall OpenAL, I get the result above.


GfK(Posted 2009) [#8]
Oddness. Here's what I just did:

1. Create a folder on desktop.

2. Put OpenAL32.dll and wrap_oal.dll in it.

3. Create a new .bmx file with this code in:
Print EnableOpenALAudio()
For s:String = EachIn AudioDrivers()
	Print s
Next
Print FileType("OpenAL32.dll")


I get this:
1
OpenAL Default
OpenAL Generic Software
OpenAL
FreeAudio
FreeAudio Multimedia
FreeAudio DirectSound
DirectSound
Null
1


I also checked that the OpenAL DLLs were not in C:\Windows\System32.

My DLL versions:
OpenAL32.dll: 6.14.0357.22
wrap_oal.dll: 2.1.8.1

32-bit Windows 7
BlitzMax 1.36

[edit] Just tried with the latest version of OpenAL (6.14.0357.24 and 2.2.0.5). Worked perfectly - same result as above.


Imphenzia(Posted 2009) [#9]
That's so odd...

I've got OpenAL32.dll: 6.14.0357.24 and wrap_oal.dll: 2.2.0.5 and do exactly as you do with no OpenAL and EnableOpenALAudio() returns false.

64-bit Windows 7
BlitzMax 1.36


JoshK(Posted 2009) [#10]
On Windows Vista and 7 OpenAL will fail to initialize on some machines if you don't actually install it with the OpenAL installer. It isn't enough just to drop the DLL in the app folder.
http://connect.creativelabs.com/openal/Downloads/oalinst.zip


Grey Alien(Posted 2009) [#11]
On Windows Vista and 7 OpenAL will fail to initialize on some machines if you don't actually install it with the OpenAL installer. It isn't enough just to drop the DLL in the app folder.
I didn't know that. Have you experienced it first hand? I distribute OpenAL with the exe and it's worked on all Vista and Windows 7 machines I've tried it on (and BFG's test lab).


JoshK(Posted 2009) [#12]
I have experienced this firsthand. See post by "trogdor" here:
http://forum.thegamecreators.com/?m=forum_view&t=136731&b=2

Looks like it is also an XP issue.


GfK(Posted 2009) [#13]
From your link:
I found out you actually have to install OpenAL on Vista, you can't just include the DLL like I did. In the future, I will just include the OpenAL installer
But it isn't a global problem. The OpenAL issue doesn't happen for me on any of my Vista PCs, or on Windows 7.

Why would this be? The DLL is either there, or it isn't?


TaskMaster(Posted 2009) [#14]
Must be some other requirement that you don't know to account for. Maybe a more common DLL that is included with something else?


GfK(Posted 2009) [#15]
I've done some googling and found, among other things, this.

Seems that there are ways to get OpenAL to not work. Now, I know chuff-all about the intricacies of such things, so.... anybody else?


JoshK(Posted 2009) [#16]
I figure the installer does something additional besides just copying the DLL. Whatever that extra thing is, some sound drivers need it, some don't.

I would just make your game installer have an option to run the OpenAL installer after installing the game.


GaryV(Posted 2009) [#17]
Why would this be? The DLL is either there, or it isn't?
You do not mention what versions of Vista or 7 you are using.

The problem is Imphenzia is not playing by the rules. He is putting the DLL in the wrong directory for a 64 bit OS:

32 bit DLLs must be placed in C:\Windows\SysWOW64
Only 64 bit DLLs can be in the system32 directory.

If you want to put a 32bit DLL in the same directory as a 32bit EXE and expect it to work you need stick with 32bit versions of Vista and 7. Otherwise, you have to play by the rules MS has set.


GfK(Posted 2009) [#18]
I would just make your game installer have an option to run the OpenAL installer after installing the game.
There are a host of problems with that, though.

1. If the user becomes aware that something extra is being installed - panic.
2. If you install it silently and they find it later they could:
a: be p*ssed off about it
b: uninstall it without realising what it is

...and what if openAL is already installed? What would happen? What if the user already has a newer version installed?

GaryV: I'm on 32-bit Windows 7 and Vista. I'm half-tempted to install Windows 7 64-bit to test the theory but I'd be raising an eyebrow if BFG's test department didn't have a single 64-bit system to test on, and apparently they've never come across OpenAL failing.


ziggy(Posted 2009) [#19]
You can load as many 32 bits dlls as you wish from a 32 bits application on windows 64 bits. Be sure to not be trying to load a 64bits dll from a 32bits exe.


Imphenzia(Posted 2009) [#20]

The problem is Imphenzia is not playing by the rules. He is putting the DLL in the wrong directory for a 64 bit OS:

32 bit DLLs must be placed in C:\Windows\SysWOW64
Only 64 bit DLLs can be in the system32 directory.



Well, the official OpenAL-installer is actually putting the OpenAL32.dll into c:\windows\system32 and if the installer is used BlitzMax finds OpenAL.

I'm guessing the installer just uses regsvr32 to register the DLL for windows awareness.


GaryV(Posted 2009) [#21]
I'm half-tempted to install Windows 7 64-bit to test the theory
MSDN, I can't claim the theory ;)

Well, the official OpenAL-installer is actually putting the OpenAL32.dll into c:\windows\system32 and if the installer is used BlitzMax finds OpenAL.
No, the OS recognizes it as a legacy application and uses virtualization.


JoshK(Posted 2009) [#22]
1. If the user becomes aware that something extra is being installed - panic.
2. If you install it silently and they find it later they could:
a: be p*ssed off about it
b: uninstall it without realising what it is

Unreal Tournament 3 does the same thing, if I remember right.

...and what if openAL is already installed? What would happen? What if the user already has a newer version installed?

There are no new versions of OpenAL. The installer has been the same for years.


GfK(Posted 2009) [#23]
After reading up on OpenAL it seems you can run the installer in silent mode, and prevent it from installing an uninstaller. Not quite sure how UAC would take to that...

I presume the likes of InnoSetup/Installshield allow you to run external installers but to be honest I can't be bothered to look.


Imphenzia(Posted 2009) [#24]

Well, the official OpenAL-installer is actually putting the OpenAL32.dll into c:\windows\system32 and if the installer is used BlitzMax finds OpenAL.

No, the OS recognizes it as a legacy application and uses virtualization.



How very correct you are :)

SOLUTION: I copied the OpenAL32.dll from C:\Windows\SysWOW64 (106kb) instead of C:\Windows\System32 (120kb virtualized file?) and it now works perfectly without OpenAL installed.

Thank you all for engaging in this thread and thanks to GaryV for pointing me to the solution.


GaryV(Posted 2009) [#25]
NP, I deal with the same 32bit DLL problem quite often at work :(


Grey Alien(Posted 2009) [#26]
So Imphenzia, where is the dll now? In the exe folder or somewhere else?


Imphenzia(Posted 2009) [#27]
So Imphenzia, where is the dll now? In the exe folder or somewhere else?


Yes, in the same folder as the .exe (or .bmx when I compile).

So just be aware where you copy the file from when you distribute it with the game, if it's from x64 get it from C:\Windows\SysWOW64 as that is the "proper" dll.


GfK(Posted 2009) [#28]
So, there are two different sets of DLLs? Never dealt with this 'virtualisation' lark so I dunno what the actual solution is here?


GaryV(Posted 2009) [#29]
It is not virtualization that was the issue. He was using the wrong DLL.

On a Vista/7 64bit, your BlitzMax stuff runs under emulation. Windows-on-Windows 64-bit is the emulation layer. On a 64bit OS, SysWOW64 is where 32bit DLLs go (can be found) and System32 is where 64bit DLLs go (can be found).

Imphenzia was grabbing the wrong DLL. ON a 64bit OS, OpenAL's installer installs 32bit and 64bit DLLs. Imphenzia was grabbing the 64bit DLL.

Since we started migrating to 7 64 at work, I deal with people putting 32bit DLLs in the System32 directory all day. As noted before, on a 64bit OS, System32 is for 64bit DLLs.

What makes it worse is some older installation programs contain trust info, but do not properly check for a 64bit OS and will install DLLs in the wrong directory. Other older installation programs do not contain trust info and can get recognized as legacy applications and it is installed using virtual locations which is not a major issue on a 32bit OS, but can create havoc on a 64bit OS.


Grey Alien(Posted 2009) [#30]
Right, so the method I use of including the 32-bit dll in the folder with the exe will still work. Good to know.


ziggy(Posted 2009) [#31]
Yes, there's no problem using the 32 bits dll from a 32 bits program on a 64 bits windows machine.


JoshK(Posted 2009) [#32]
I thought LoadLibraryA() would preferentially load the DLL that was in the application directory?


Mr. Write Errors Man(Posted 2009) [#33]
Windows (since some XP SP) checks DLLs first from system folders, only then from the "folder with the exe". Even if the ones in system folders are older versions etc.


JoshK(Posted 2009) [#34]
Windows (since some XP SP) checks DLLs first from system folders, only then from the "folder with the exe". Even if the ones in system folders are older versions etc.

That is odd, because glIntercept works by dropping a dummy of OpenGL32.dll in the application directory.

So the solution is to use LoadLibraryA(appdir+"/OpenAL32.dll") to ensure your copy of the 32-bit DLL is loaded?