An internal OpenAL call failed in sound.cpp (57)

[nitram_cero]

I get this error:

An internal OpenAL call failed in sound.cpp (57) : AL_INVALID_ENUM, an unacceptable value has been specified for an enumerated argument

When I create a "new sf::Sound(some_buffer);"

It gets me to this line

Code: [Select]

ALCheck(alSource3f(mySource, AL_POSITION, Copy.GetPosition().x, Copy.GetPosition().y, Copy.GetPosition().z));


The sounds still play correctly.

Maybe an alEnable(AL_DISTANCE_MODEL) call is missing? I don't know sh*t about OpenAL, but by intuition that "INVALID_ENUM" means AL_POSITION is not very welcome by the function.

[Laurent]

This is strange, I checked the documentation again and it seems everything is ok in this call. And actually, you're the first one to report such an error, so far. Did you try the current SVN version of SFML?

[nitram_cero]

I have SVN version 950 (latest SVN for /src/SFML/Audio is 919)

Is there any useful information I can give you? Maybe it has something to do with my soundcard (nVidia nForce)?

I don't know, it just happens. I'm downloading the OpenAL source to see if I can help.

EDIT: AL_INVALID_ENUM is only set when it doesn't recognize the second parameter, maybe VC++ f*cked up, I'll try rebuiliding SFML. Thanks.

-Martín

[Laurent]

Sorry, I have absolutely no clue :?

[Nexus]

I have already had a similar error (also "internal OpenAL call failed"), I think it occured because something was wrong with de OpenAL32.dll. I downloaded it again and it worked...

[nitram_cero]

Thanks a bunch! I'll try it now.

Oh... now I remember, I have PATH'd the OpenAL32.dll that came with SFML 1.3 and then built the SFML from svn.

Maybe the OpenAL guys change some constants in each build... that's crap man, they shouldn't, like OpenGL.

Sorry for the troubles.

EDIT: I did as Nexus said and it worked.
I think that some app/game installed OpenAL on windows/system32.
That directory has more precedence in the enviroment variable PATH than the one I use to dump all sdk's dlls.

I think that if the OpenAL32.dll is in the same directory as the application, then this won't bother at all.
Problem solved.

Thanks again!
-Martín