Page 1 of 2
OpenAL SDK for PureBasic
Posted: Wed Mar 07, 2007 2:46 am
by Quantum
Download:
http://sourceforge.net/project/showfile ... _id=491761
Current release contains:
[*] The OpenAL UserLib itself (not a wrapper!). Mostly the same as the one I previously released with the ImpLib package, only that this new lib produces a smaller import directory, meaning a smaller executable as well.
[*] The complete OpenAL API reference in CHM format for inline access from the IDE.
[*] Some examples taken from the official SDK and ported to PB: static buffer playback, streaming, device and effects enumeration.
Well, that's all.
Posted: Wed Mar 07, 2007 8:45 pm
by Num3
OMG !!!
Awsome !!!!
Posted: Wed Mar 07, 2007 9:01 pm
by Quantum
From the official OpenAL website:
"OpenAL is a cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications."
The key difference with other similar APIs is it's support for hardware-accelerated advanced environmental effects. You can take advantage of the latest Creative features (like XRAM!) using OpenAL. And it becomes even more important when targeting Vista

Posted: Wed Mar 07, 2007 9:23 pm
by Psychophanta
Quantum wrote:You can take advantage of the latest Creative features (like XRAM!) using OpenAL
That's nice!!
Thanks

Posted: Thu Mar 08, 2007 2:26 pm
by Brice Manuel
Definitely, one of the most valuable contributions to the community.
Posted: Sat Mar 10, 2007 10:30 am
by Rescator
Awesome, I was chugging along on my own "port" to PB but as my sound needs was not that "needy" yet it took ages between each time I did anything new to the code!
I hope you contacted OpenAL.org to get it listed on their site?
Posted: Sat Mar 10, 2007 10:46 am
by Rescator
Something odd with the port of the framework files though.
I keep getting "-ERR: Could not initialize OpenAL"
the official SDK examples work fine.
Not sure if it's a ANSI/Unicode issue or whatnot but basically it looks like the framework includes return 0 devices in the device list.
Posted: Sat Mar 10, 2007 1:48 pm
by flaith
Num3 wrote:OMG !!!
Awsome !!!!
Like all of its programs
Posted: Sat Mar 10, 2007 11:19 pm
by Quantum
Rescator wrote:Something odd with the port of the framework files though.
I keep getting "-ERR: Could not initialize OpenAL"
the official SDK examples work fine.
Not sure if it's a ANSI/Unicode issue or whatnot but basically it looks like the framework includes return 0 devices in the device list.
The precompiled examples don't work either? Could you please compile and run it in debug mode to check where exactly is it failing? It is very possible that the error has to do with LinkedList implementation. For example, in Enumerate.exe the only possible condition to get an "-ERR: Could not initialize OpenAL" error is that the devices list is empty. Normally that means you have an old OpenAL version not supporting device enumeration, but since the same feature works fine in the official SDK, the error is more likely in the linked list itself... Well, I think we'll fix this ASAP
Added:
I'v got a theory

According to the official SDK documentation alcIsExtensionPresent return ALC_TRUE on success, which is equal to 1. Maybe, the SDK is wrong and this function might return something <> 0 instead of exactly 1. So, what if you try replacing the following line in framework.pb:
Code: Select all
If alcIsExtensionPresent(0, "ALC_ENUMERATION_EXT") = #ALC_TRUE And devices <> 0
with
Code: Select all
If alcIsExtensionPresent(0, "ALC_ENUMERATION_EXT") <> #ALC_FALSE And devices <> 0
?
Rescator wrote:I hope you contacted OpenAL.org to get it listed on their site?
Like a month ago... No response since then. Maybe they didn't like the fact I also reported some bugs in the SDK... Most PB developers read this forum, so not getting listed @ openal.org is not a big deal, I think.
Posted: Sun Mar 11, 2007 8:43 am
by Fred
Very good work !
Posted: Sun Mar 11, 2007 6:50 pm
by Rescator
Yep your right Quantum, the SDK is wrong!
Changing it to
Code: Select all
(alcIsExtensionPresent(0, "ALC_ENUMERATION_EXT") <> #ALC_TRUE) And (devices <> 0)
fixed it!
It seems on my system it returns numeric 268493057 (hex 1000E101)
I haven't checked what that is though.
PS! I got a Creative Audigy 2 ZS if that helps in any way and the latest OpenAL libs and latest unified drivers for Audigy.
All Available OpenAL Devices:
SB Audigy 2 ZS Audio [DC00], Spec Version 1.1
Generic Hardware, Spec Version 1.1
Generic Software, Spec Version 1.1
Default device: SB Audigy 2 ZS Audio [DC00]
Devices with XRAM support:
None
Press any key to exit
Hey nice, finally the native driver is v1.1 for the longest time it was only 1.0 (so recording etc. was only possible with one of the generic ones) typical
PS! For those with no clue the Generic Hardware is actually DirectX and the Generic Software is WaveIn/Out unless I'm mistaken? On Linux and Mac those two are mapped to something else obviously.
Ironically, on Vista Generic Hardware and Software are the same isn't it? *laughs*
Posted: Sun Mar 11, 2007 7:06 pm
by Rescator
PS! The examples etc are not unicode compatible.
As far as I know OpenAL dll is ANSI only?
Yep, just checked, seems you need to fix all instances of PeekS to
PeekS(devices,-1,#PB_Ascii) for example.
Edit:
And PeekS(defaultDeviceName,-1,#PB_Ascii)
both in the framework file, seems the rest of the files don't need any changing as they don't use PeekS.
Gah wait, what about the places when text is passed to OpenAL, those need to be ansi only.
Posted: Sun Mar 11, 2007 7:32 pm
by Rescator
Bah another post. Anyway...
I notice that you do not include alGetDouble you really should as PB4 support returning of doubles.
I'm a bit unsure on how to handle the strings returned by OpenAL
is it possible to make alcGetString return type as String instead of Any?
(I know, some of the OpenAL strings is a list of strings with zero terminations so.) You might want to poke Fred or someone in the PB team for tips on that.
alcIsExtensionPresent, Any, Any, (*device, *extname) for example should be
alcIsExtensionPresent, Long, String, (*device, *extname) shouldn't it?
Or maybe I'm talking crap, I'm pretty much a noob when it comes to PB libs and the way OpenAL does it doesn't make it easier heh!

Posted: Sun Mar 11, 2007 10:09 pm
by Quantum
Rescator wrote:For those with no clue the Generic Hardware is actually DirectX and the Generic Software is WaveIn/Out unless I'm mistaken?
Yes, Generic Software is good ol' KMixer ;) That's why Generic Hardware usually sounds louder.
PeekS(defaultDeviceName,-1,#PB_Ascii)
OK. That's a new feature in PB4, so it seems like I'll have to make a separate framework for PB4. I didn't notice PB4 supports Unicode API, so thanks for the tip.
Gah wait, what about the places when text is passed to OpenAL, those need to be ansi only.
WideCharToMultiByte should be used in case Unicode is enabled.
I notice that you do not include alGetDouble you really should as PB4 support returning of doubles.
You can use alGetDoublev in both PB3 and PB4 instead of alGetDouble. Do you think it's a good idea making 2 separate UserLibs for PB3 and PB4?
is it possible to make alcGetString return type as String instead of Any?
No, because it doesn't return a PB string, but an ASCIIz string. I can make it automatically translate ASCIIz to PB like I did in uFMOD UserLib though... But you already noted there whould be a problem with null-separated string arrays.
I'll fix the samples, add a couple of new ones and release an update.
Posted: Mon Mar 12, 2007 1:18 am
by Rescator
Separate PB3 and PB4 would reduce the size/quirks needed to make it work on both, and take advantage of the unicode feature yeah. That would be great!