Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

openAL error when calling sf::SoundBuffer::loadFrom*() more than once #354

Closed
Ancurio opened this Issue · 18 comments

7 participants

@Ancurio

Minimal example:

#include <SFML/Audio.hpp>
#include <SFML/System.hpp>

int main(int, char**)
{
    sf::SoundBuffer buffer;
    buffer.loadFromFile("sound1.ogg");

    sf::Sound sound(buffer);
    sound.play();

    sf::sleep(sf::seconds(5));

    buffer.loadFromFile("sound2.ogg");
    sound.setBuffer(buffer);
    sound.play();

    sf::sleep(sf::seconds(5));

    return 0;
}

"sound1.ogg" is played the second time, instead of "sound2.ogg". Apparently the openAL error is

An internal OpenAL call failed in SoundBuffer.cpp (253) : AL_INVALID_VALUE, a numeric argument is out of range
@eXpl0it3r
Owner

The discussion on the forum can be found here.

@kd7tck

I did a quick fix, works but really sloppy.

kd7tck@3efea48
Cherry pick it if you want to try it out.

@kd7tck

Here is a newer diff file, hurry on it. Mega tends to delete things after a couple weeks.

https://mega.co.nz/#!uYBU2Q7C!eUmZuwAjmgZqMkRqcXSH6gk0FEA7PhetCEepWy8I0dc

I also updated my commits with a correction.

@Ancurio

Mega tends to delete things after a couple weeks.

Why not just use pastebin?

@LaurentGomila

Why not just use pastebin?

Or github's gists...

@kd7tck

This will be easier to access.

edit.
kd7tck@6e8f6ba

kd7tck@71c62cf

@kd7tck

Any more Ideas on how I should clean the patch up further?

@Foaly

Hmm... Does this issue only happen with loadFromFile() ? Because if it also happens with the other load methods you should put your code in the initialize() method. I think you have to do some more investigation/testing.

Edit: I just saw that the loadFromSamples() method doesn't call initialize() , so if loadFromSamples() has the same error you might want to put your code in a seperate method (maybe something like unload()). Either way you should test a little more and see what you find out.

@kd7tck

I did a quick modification and test, seems to work. Look over and tell me if changes will fit.

@Foaly

This looks better. But I find the return type confusing, because it says if it returns false, the function failed to unload the buffer, but it actually means there is nothing to unload. Also I find unload more clear, because you are not reloading anything, you are reseting and clearing the buffer.
What about loadFromSamples() have you tested if the problem also persists there? Also have you actually done some testing with the other load functions before and after your fix?
We'll see what Laurent says.

@kd7tck

There are two audio patch branches each with a different approach. The second audio_patch is the one I prefer, but does not work with loadFromSamples(). In that case you would need the first patch, which can easily be applied to loadFromSamples() if you wanted. I did tests with all load functions, turns out they all have this bug including the loadFromSamples().

#include <SFML/Audio.hpp>
#include <SFML/System.hpp>

int main(int, char**)
{
    sf::SoundBuffer buffer, buffer2;
    buffer.loadFromFile("cars001.wav");
    buffer2.loadFromSamples(buffer.getSamples(), buffer.getSampleCount(), buffer.getChannelCount(), buffer.getSampleRate());

    sf::Sound sound;
    sound.setBuffer(buffer2);
    sound.play();

    sf::sleep(sf::seconds(5));
    sound.stop();
    buffer.loadFromFile("cars002.wav");
    buffer2.loadFromSamples(buffer.getSamples(), buffer.getSampleCount(), buffer.getChannelCount(), buffer.getSampleRate());

    sound.setBuffer(buffer2);
    sound.play();

    sf::sleep(sf::seconds(5));

    return 0;
}

I will reword the comment in the next commit.

@Foaly

I like the second commit better too. But there is one thing I don't get. If you put a reload(); before this line, does the problem still persist? Because the fix will obviously not be applied if it only works for 3 out of 4 load methods.
Also I still think that unload() would be a more discribtive name, but Laurent will have to decide that.
Once you have done all the changes, I would make one clean pull request, so Laurent can merge it easily.

@abodelot

Foaly commented:

But I find the return type confusing, because the function failed to unload the buffer, but it actually means there is nothing to unload. Also I find unload more clear, because you are not reloading anything, you are reseting and clearing the buffer.

That's a good point. But why does the reload method returns a boolean in the first place? The returned value is never used, so void may be more suitable (and less confusing).

@kd7tck

Noted.

@kd7tck

@Foaly, If reload is placed behind loadFromSamples() it works.

@kd7tck

Here is the corrected first patch

kd7tck@82c621f

@binary1248 binary1248 referenced this issue from a commit
@kd7tck kd7tck Fixed soundbuffer contents not being able to be updated when still at…
…tached to sounds (#354).

Signed-off-by: binary1248 <binary1248@hotmail.com>
6fb4fce
@binary1248
Owner

I rewrote the submitted patch to not require any changes to the public API. kd7tck is attributed as the author since it was his work and initial implementation.

@binary1248 binary1248 self-assigned this
@binary1248 binary1248 referenced this issue from a commit
@kd7tck kd7tck Fixed soundbuffer contents not being able to be updated when still at…
…tached to sounds (#354), sounds now detach from their buffer when it is reset. Signed-off-by: binary1248 <binary1248@hotmail.com>
38a2100
@eXpl0it3r eXpl0it3r referenced this issue from a commit
@kd7tck kd7tck Fixed soundbuffer contents not being able to be updated when still at…
…tached to sounds (#354), sounds now detach from their buffer when it is reset. Signed-off-by: binary1248 <binary1248@hotmail.com>
0375d75
@eXpl0it3r
Owner

Issue has been resolved through pull request #589 and got merged in 0375d75.

@eXpl0it3r eXpl0it3r closed this
@eXpl0it3r eXpl0it3r modified the milestone: 2.2, 2.x
@eXpl0it3r eXpl0it3r added resolved and removed confirmed labels
@MarioLiebisch MarioLiebisch referenced this issue from a commit in MarioLiebisch/SFML
@kd7tck kd7tck Fixed soundbuffer contents not being able to be updated when still at…
…tached to sounds (#354), sounds now detach from their buffer when it is reset. Signed-off-by: binary1248 <binary1248@hotmail.com>
0df8695
@jcowgill jcowgill referenced this issue from a commit in jcowgill/SFML
@kd7tck kd7tck Fixed soundbuffer contents not being able to be updated when still at…
…tached to sounds (#354), sounds now detach from their buffer when it is reset. Signed-off-by: binary1248 <binary1248@hotmail.com>

(cherry picked from commit 0375d75)
8f36628
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.