Is it possible to use SFML just as an OpenAL wrapper?

[k6l2]

I'm running an application using another library for drawing stuff to the window, but I really like the audio portion of SFML, as well as a few other parts of the library such as input handling and networking..  Is there some way to initialize just the OpenAL internals without creating a RenderWindow?

I tried just using the API in sf::Listener and I just get a bunch of OpenAL errors which I assume is because the internals are not being initialized properly.

More specifically, when I try calling sf::Listener::setPosition for example, I get a bunch of

An internal OpenAL call failed in AudioDevice.cpp (173) : AL_INVALID_OPERATION,
the specified operation is not allowed in the current state

[Nexus]

I'm running an application using another library for drawing stuff to the window, but I really like the audio portion of SFML, as well as a few other parts of the library such as input handling and networking..  Is there some way to initialize just the OpenAL internals without creating a RenderWindow?

Yes of course, SFML is modular. You only need the sfml-system and sfml-audio modules.

More specifically, when I try calling sf::Listener::setPosition for example, I get a bunch of

An internal OpenAL call failed in AudioDevice.cpp (173) : AL_INVALID_OPERATION,
the specified operation is not allowed in the current state

Make sure you're using the latest SFML revision from GitHub (2.3.x branch). This is important, as one bug has been fixed quite recently.

If the problem persists, please provide a minimal complete example.

[k6l2]

Oh my bad, it seems I was using an out of date version...

#define SFML_VERSION_MAJOR 2
#define SFML_VERSION_MINOR 1

I will try with an up-to-date build and follow up on this when I get the chance!

[k6l2]

So even after I upgraded my version of SFML, the problem persists.  As requested, here is the minimal complete example:

#include <cstdlib>
#include <SFML/Audio.hpp>
int main(int argc, char** argv)
{
    sf::Listener::setPosition(rand()/(float)RAND_MAX*20.f, 0, 0);
    return EXIT_SUCCESS;
}
 

This results in the previously mentioned AL_INVALID_OPERATION.  I did some testing and found two interesting things about this.

• If I call setPosition(0,0,0) instead of some random value, the AL_INVALID_OPERATION does not occur.
• If I just create an instance of sf::Music (and do nothing with it) before the call to sf::Listener::setPosition, the AL_INVALID_OPERATION does not occur

Thoughts?

[Hapax]

I'm going to avoid commenting on your choice to use rand() but is it necessary for the minimal example? For instance, does you still have the error if you put a direct value there? If so, that's minimal, and you can leave off the other library 

It fails for me too but I'm only using the the release version of 2.3 and I'm not sure if the fix was before or after the release.

If you visit Nexus' link ("one bug"), you'll see that the temporary workarounds you describe have already been discussed (created an audio object before using the listener).

EDIT: changed "solutions" to "temporary workarounds" to clarify that they are not solutions but temporary workarounds () until it was fixed, which it is, in the correct version, as Nexus has said.

[Nexus]

It still suspiciously looks like the bug I have linked to.

Which version of SFML are you using exactly? The SFML 2.3.1 release is not enough, I hightlighted that you'd need the latest GitHub revision of the 2.3.x branch

There's no need for workarounds like audio objects before the listener, as the bug has been fixed meanwhile.

[k6l2]

I'm going to avoid commenting on your choice to use rand() but is it necessary for the minimal example? For instance, does you still have the error if you put a direct value there? If so, that's minimal, and you can leave off the other library 

Hahahah!  You know as well as I do that the rand() call has nothing to do with this..  Also you failed to "avoid commenting" on it   But for the record since you mentioned it, it happens even when I call "sf::Listener::setPosition(20.f, 0, 0);"

It still suspiciously looks like the bug I have linked to.

Which version of SFML are you using exactly? The SFML 2.3.1 release is not enough, I hightlighted that you'd need the latest GitHub revision of the 2.3.x branch

There's no need for workarounds like audio objects before the listener, as the bug has been fixed meanwhile.

Yeah I just checked out the link you sent me.  It does look very similar!  I did a fresh clone of SFML's repo, the version I tested on was on this commit (still version 2.3.1):

fe58971 Mario Liebisch 13 hours ago  (origin/bugfix/xperia-touch) Android: Accept touch events from "multiple" devices

Edit: apologies, I copied the wrong line in git log.  It was here:

c55b8c1 Ferdinand Thiessen 12 days ago  (HEAD, origin/master, origin/HEAD, master) Fixing #935: Secure function against random data return.

[dabbertorres]

Actually, I'm looking at the tree for 2.3.x

https://github.com/SFML/SFML/blob/2.3.x/src/SFML/Audio/Listener.cpp
https://github.com/SFML/SFML/blob/2.3.x/src/SFML/Audio/AudioDevice.hpp
https://github.com/SFML/SFML/blob/2.3.x/src/SFML/Audio/AudioDevice.cpp

And I'm not seeing anything creating a new AudioDevice, except for isExtensionSupported and getFormatFromChannelCount. The rest of the functions aren't creating one if needed. Unless I'm missing something?

[Hapax]

According to the thread in the link posted earlier by Nexus, the problem was this line but it seems to still be there in 2.3.x

You know as well as I do that the rand() call has nothing to do with this..  Also you failed to "avoid commenting" on it   But for the record since you mentioned it, it happens even when I call "sf::Listener::setPosition(20.f, 0, 0);"

My point was that rand() and the library that it requires should not be in the minimal example if it's not causing the problem. The more (unnecessary) things included, the more things that have to be examined.
Also, I didn't say that I was going to avoid commenting about rand() being there, I said I was going to avoid commenting on your choice to use it at all. However, since you brought it up... 
Don't use rand() 

EDIT: fixed "this line" link.

[Nexus]

@k6l2: So the problem is still there with the latest SFML commit?
And Hapax is right, don't use rand(). You'll find explanations across the Internet, for example here.

@dabbertorres: If I remember correctly, the audio device is lazily initialized, i.e. only when sounds/music is used, not by the listener itself. Which is semantically fine, because setting the listener values alone has no effect on audio and thus doesn't require OpenAL.

@Hapax: The link doesn't work, but I guess I know which line you meant. The bug is fixed even though the line has not been changed, because I corrected the alCheck macro.

[Hapax]

I fixed the link although it doesn't matter now since you mentioned the problem code (that was modified) was the macro that it refers to.

[k6l2]

@k6l2: So the problem is still there with the latest SFML commit?

At the time when I posted that reply that I updated to a fresh clone of the SFML repository, yes.

Also lol... Everyone keeps mentioning my inclusion of rand()... I now feel obligated to explain myself:  I did it to emphasize that it doesn't matter what value the vector supplied to sf::Listener::setPosition is, as long as it isn't zero.  I know full and well that rand() is bad, and I can assure you all that I don't actually use rand() in real code. Example code is supposed to be just that: an example.

It is worth mentioning though, that I am very glad the people here know their shit, and are willing to show newbs the proper path!  Carry on, sirs/madams.

[Nexus]

Sorry for annoying you again, but I really want to be sure we're talking about the same, as I cannot reproduce it with the latest version

Can you try this minimal code:

#include <SFML/Audio/Listener.hpp>
int main()
{
    sf::Listener::setPosition(20.f, 0.f, 0.f);
}

You said you use the commit c55b8c1, however the latest commit of branch 2.3.x has the SHA-1 0f1dc5a. The commit message is in both cases "Fixing #935: Secure function against random data return."

With that commit, the error output should be different than in your initial post. Can you show the new one?

Furthermore, which operating system, compiler and compiler version are you using? How are you linking SFML?