-
The closest thing that I could find that already mentioned this error is this post (http://en.sfml-dev.org/forums/index.php?topic=14506.0) but since the error I'm getting is in SFML 2.3 but not 2.2, I don't think that topic is relevant - barring the fact that it didn't seem that the problem in the thread had a solution.
The actual error I'm receiving is:
An internal OpenAL call failed in AudioDevice.cpp (157) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state
#include <SFML/Audio.hpp>
int main()
{
sf::Listener::setGlobalVolume(100.f);
return EXIT_SUCCESS;
}
That code is enough for me to get the error. It doesn't get an error by instancing an sf::Sound object (like in this SFML Github issue (https://github.com/SFML/SFML/issues/30) that I visited to see if it was related) instead of using the Listener. In fact, after some extra tests while writing this, I found that of the setters in Listener, setGlobalVolume() and setPosition() causes the error but setDirection() and setUpVector() do not.
I've fully linked to 2.3 and it causes this error. I then fully linked to 2.2 and there is no error.
I then tried 2.3 with 2.2's Audio dll and the error disappears. 2.2 with 2.3's Audio dll brings it back.
Both versions of the SFML DLLs are the release versions.
Indeed, the reason I noticed this was because I linked my Faux Car project to 2.3 and it caused this error at the very beginning (when setting global volume) and then I had some weird destruction crash when main() closed. I've found the source of the crashing so they're not related as I originally considered. I addressed this first (the audio error) as it's the first error and I found it easy to reproduce with minimal code.
EDIT: This error is only appearing in debug mode, not release.
Windows 7 64-bit, VS Studio 2013, SFML 32-bit - dynamic and static both same result.
EDIT 2:
64-bit gives same result as 32-bit (debug, not release; both dynamic and static same result).
-
I could not reproduce.
Windows 8.1 64-bit
VS 2013
SFML 32-bit.
I can try Linux tomorrow.
-
Windows 8.1 64-bit
VS 2013
SFML 32-bit.
Did you try it in debug mode?
I can reproduce it in
Windows 8.1 x64
MinGW 5.1.0
SFML 2.3 x86 static
-
Cannot reproduce in debug mode.
Windows 7 Enterprise x64
MinGW 5.1.0
SFML 2.3 x64 dynamic
EDIT: I also tested SFML 2.3 x64 static on the same machine, still no issues.
-
I have this issue only in Static Debug.
Windows 8.1 64-bit
VS 2012
SFML 2.3 x86 Static.
-
Is it possible for you to confirm that the error was not present in 2.2?
Kitteh-warrior, can you test it in SFML 32-bit to see if you have a different result?
I will test my SFML 64-bit now...
...tested 64-bit and - for me - gives the same results as 32-bit (debug, not release; both dynamic and static same result).
I've modified the original post to include my 64-bit results.
-
I tried with MinGW in 32-bit mode with SFML debug for both dynamic and release. Still no error.
Hapax, could you provide the compiled binary of the example that is causing a problem?
Edit: fixed the wording
-
Hapax, could you provide the compiled binary of the example that is causing a problem?
Good idea.
Here's a static debug executable that causes the error (for me). openal32.dll is included (obviously).
http://www.mediafire.com/download/mqp1254xqfyveht/CausesAudioError.zip
-
Just found an odd 'solution'. It might not be odd to someone who knows why it works as it may be expected.
Basically, if you contruct an sf::Sound before setting the global volume of the listener, no error is given, thus:
#include <SFML/Audio.hpp>
int main()
{
sf::Sound sound;
sf::Listener::setGlobalVolume(100.f);
return EXIT_SUCCESS;
}
That seems to work fine so at least it's a workaround for now.
p.s. actually, creating an sf::Sound, sf::SoundBuffer, or sf::Music object before the Listener line, clears the error.
-
I tested your executable with the openal32.dll in the same directory, and it gave the same error that you were getting.
I moved the DLL to another directory (thinking that maybe the one in my system might not give the same error), and the error went away.
Try installing this into your system, and removing the previous DLL's: http://www.openal.org/creative-installers/oalinst.zip
This is what I just installed today to test your example.
-
No, don't do that!
SFML is written for OpenAL Soft and not for the outdated Creative version.
-
SFML is written for OpenAL Soft and not for the outdated Creative version.
Opps, sorry. I forgot that it used OpenAL Soft, and when the error came up (of missing OpenAL32.dll), I just got the OpenGL Creation version. I downloaded OpenAL Soft, and placed the DLL in the correct location and the error is coming up as it did with Hapax and eXpl0it3r.
-
After all it's more or less just a warning and in a real application chances are probably rather low to run into this. Given the message I assume there's just something (OpenAL contex?) that needs to be "initialized" before one can use the function.
-
It looks like the OpenAL device is not initialized. Earlier, there were function calls ensureALInit() to make OpenAL ready, but those were removed in this commit (https://github.com/SFML/SFML/commit/0ad401cc97e5577f594066d3c993daca803572e8). The new architecture relies on the initialization of an AlResource object to trigger the initialization -- and sf::Listener bypasses that.
After all it's more or less just a warning and in a real application chances are probably rather low to run into this.
I think it's relatively common to set configuration values like volume before playing any sounds... I'm not sure if the user settings are applied correctly in that case.
I'll have a closer look.
[Edit] So far, I struggle to reproduce the problem...
-
Okay, that's one sneaky bug :D
void AudioDevice::setGlobalVolume(float volume)
{
if (audioContext)
alCheck(alListenerf(AL_GAIN, volume * 0.01f));
listenerVolume = volume;
}
In this code, the OpenAL call is executed even if audioContext is NULL.
How is this possible? alCheck() is not a function, but an macro that's implemented in a way how you should not implement macros:#ifdef SFML_DEBUG
#define alCheck(x) x; sf::priv::alCheckError(__FILE__, __LINE__);
#else
#define alCheck(Func) (Func)
#endif
See? Two statements, and only the first is executed in an if-branch.
By the way, the conditional compilation also explains why it only happens in debug mode.
I'll fix it as soon as possible.
[Edit] Fix is available in the bugfix/alcheck_macro (https://github.com/SFML/SFML/tree/bugfix/alcheck_macro) branch.
I would like to do something similar for glCheck(), because such macros are bloody time bombs. Unfortunately, there's a lot of client code that currently relies on these strange semantics :-\
-
Windows 8.1 64-bit
VS 2013
SFML 32-bit.
Did you try it in debug mode?
Sorry, should've clarified, I tried both Debug and Release.
Only dynamic though, not static. (it was 2 AM. :) )
Though, it looks like VS doesn't define DEBUG automatically in Debug builds (grumble grumble), it defines _DEBUG (note the underscore). So that'd be why I could not reproduce. I can try again after work, thought it looks like that may be redundant.
@Nexus:
Yeah, when googling and looking at the Github I thought that macro was pretty... interesting. The two statement macro + if-statement without braces didn't click for me though.
Heh, that may be why my workplace's coding standards require braced if-statements...
But yeah, you're right. Who knows what else could be caused by similar errors? I'm interested in the effects on client code. I'll try that branch out on some of my existing code and see if anything breaks.
-
While you are at it, you might want to fix the glCheck(...) (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/GLCheck.hpp#L46) function also.
-
While you are at it, you might want to fix the glCheck(...) (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/GLCheck.hpp#L46) function also.
Yup: :)
I would like to do something similar for glCheck(), because such macros are bloody time bombs.
I renamed the branch to bugfix/robust_check_macros (https://github.com/SFML/SFML/tree/bugfix/robust_check_macros) because it handles both alCheck and glCheck. I used the opportunity to improve the diagnostic output of those macros, mainly by incorporating the expression string and making the log more readable. Instead of:
An internal OpenGL call failed in userfile.cpp(50) : GL_INVALID_ENUM, an unacceptable value has been specified for an enumerated argument
the output is now:An internal OpenGL call failed in userfile.cpp(50).
Expression:
glBegin(GL_TRIANGLES)
Error description:
GL_INVALID_ENUM
An unacceptable value has been specified for an enumerated argument.
Still needs testing, feel free to experiment :)
-
Wow, Nexus. That was blooming quick! :o
The new error message format looks miles better too.
Looks promising :)
-
I would like to do something similar for glCheck(), because such macros are bloody time bombs.
Woops :/ Missed that xD
Anyways, the new error messages look good :D