PDA

View Full Version : [OpenAL] Weird problem with alSourceUnQueueBuffers



chronozphere
08-01-2008, 07:38 PM
Hey all

I've got a VERY nasty openAL problem here.

I want to get OGG working with OpenAL, which should be considerably easy, but it seems that in gamedev 9 of 10 things aren't as easy as the seem. :cry:

I used almost 100% of the "Ogg player" code, located here:

http://www.noeska.com/doal/tutorials.aspx

This code uses the old OpenAL headers which do not dynamicly load the OpenAL DLL. I used the new header, but it doesn't seem to work.

When alSourceUnQueueBuffers is called in the TOggStream.Update routine, an AV at adress $00000000 with read $00000000 is raised. Normaly this means that something is not initialized.

I have checked the Proc-var which contains the alSourceUnQueueBuffers routine, but AFAIK everyting is allright :? (Edit: I didn't check it correctly... the Procvar was NIL :oops: )

I really don't have a cleu what causes this, and the most annoying thing is, that there isn't much to debug :x

Can someone PLEASE take a look at this?

Thanx

P.S: You can just download the code, and the new "OpenAL.pas" header. When you're done, you should remove al, altypes and alut from your uses-clause, and add OpenAL instead. After that, you only have to add a call to "InitOpenAL" in the Form.Create, before ANY other openAl routine is called. :)

P.P.S: I also tested this on my XP laptop, so it's definitly not a driver bug, which means WE SHOULD BE ABLE to solve it, i guess :)

chronozphere
09-01-2008, 03:42 PM
I solved this bug :D



When alSourceUnQueueBuffers is called in the TOggStream.Update routine, an AV at adress $00000000 with read $00000000 is raised. Normaly this means that something is not initialized.


This first assumption seemed to be right. The alSourceUnQueueBuffers routine is infact a procvar. I have checked it, but i guess i did something wrong. :? Now it seems that this variabele doesn't get initialized because of a bug in the header.

I found out that alGetProcAddress or GetProcAdress are case sensitive. Apparently the function name was incorrect (It must be "alSourceUnqueueBuffers" with a lowercase 'q'). So it could not be found in the OpenAL32 dll, and it was set to NIL. The result is an AV. :)

I changed the alProcedure routine to this:



function alProcedure(ProcName : PChar) : Pointer;
begin
Result := NIL;
if Addr(alGetProcAddress) <> NIL then
Result := alGetProcAddress(ProcName);
if result <> NIL then
exit;
Result := GetProcAddress(LibHandle, ProcName);

//check whether succesfull
if Result = nil then OutputDebugString(PChar('Failed to load routine: '+ProcName));
end;


This is better, because you get a notification when some function is not loaded correctly :)

This way, i found two other functions that could not be loaded:


alHint (It was not present in the OpenAL32 DLL (OAL V1.1) so i removed it)
alDopplerModel (should be "alDistanceModel")


This shows again that a simple typo (which wasn't even mine) can mess up the whole app. :shock: I'm glad i found the sollution :)

noeska
10-01-2008, 04:59 PM
What version of openal.pas were you using? You know the latest is available on http://webpm.noeska.net
You need to login with anonymous/anonymous

chronozphere
10-01-2008, 06:36 PM
As far as i can see, the bug is present in both files (v1.0 and v1.1) :)

noeska
10-01-2008, 06:38 PM
Yes you are right.