Seeking function in sf::Music

[Laurent]

I don't see how there would be a problem with licensing. Libsndfile is LGPL, my project is LGPL, and SFML is zlib. Is there a conflict between these that I haven't heard of?

No
If your project is LGPL itself then it's fine.

Besides, I don't use dlls or anything related to shared libraries because I'm making the code as cross platform as possible (and easily usable on systems like the iphone). So static linking from compiled sources is much much easier for me to do

Ok I see. I do the same (whenever possible), but now the Linux guys want me to make it possible to link against shared libraries (so that users can update to newer versions of these libraries). And I think they're right

[Laurent]

I tried the play/stop/play stuff with the current trunk (SFML 1.6), it works fine.

The code I used is the Sound sample, with Music.Play() replaced with

Code: [Select]

Music.Play();
sf::Sleep(2);
Music.Stop();
Music.Play();

Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.

If it doesn't help, you can try the Sound sample like I did. If it works then you probably have an error in your own code.

[alaterale]

I tried the play/stop/play stuff with the current trunk (SFML 1.6), it works fine.

The code I used is the Sound sample, with Music.Play() replaced with

Code: [Select]

Music.Play();
sf::Sleep(2);
Music.Stop();
Music.Play();

Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.

If it doesn't help, you can try the Sound sample like I did. If it works then you probably have an error in your own code.

I just tested out the Sound sample according to your changes, and it does work.  It was very easy to test out the sample with my existing build system by just replacing the contents of my main.cpp file with the sample Sound.cpp  I'm glad the samples here are pretty small and easily readable, also goes to show how much little setup is needed to get something running (one of the reasons I really like this library).

Anyway, it looks like I was doing everything you are doing, except for one thing.  I wasn't using those sf::Sleep commands anywhere.  Commenting out the one you put in there into the sample recreates the same issue I am having.  So I guess I'm having some kind of threading problem?  Not giving enough sleep time inbetween calls to the SFML audio components?  Is there some sort of guide to follow on how/when to put those calls in?  Should I be putting sf::sleep calls in my mainloop for each music file that is playing?  I've done some multithreaded programming before, but it's never been my strong point

Putting a Play(), sleep(2), stop(), play(), sleep(2), in my code, is giving me a similar thing as before, where it starts playing, stops, and then doesn't play again on the second play().  Any tips?

At least I'm getting this resolved though and it looks like it's just a matter of proper threading

[Laurent]

I wasn't using those sf::Sleep commands anywhere. Commenting out the one you put in there into the sample recreates the same issue I am having. So I guess I'm having some kind of threading problem? Not giving enough sleep time inbetween calls to the SFML audio components?

So you mean that you call Stop() right after Play()?
Anyway, calling play/stop/play without any delay (ie. commenting the sf::Sleep call) still works for me.

Should I be putting sf::sleep calls in my mainloop for each music file that is playing?

No, it should work fine under all circumstances. If there's any issue related to multi-threading, then it's a bug in SFML

Putting a Play(), sleep(2), stop(), play(), sleep(2), in my code, is giving me a similar thing as before, where it starts playing, stops, and then doesn't play again on the second play(). Any tips?

Hum? Isn't it the exact same thing that I did?

[alaterale]

I wasn't using those sf::Sleep commands anywhere. Commenting out the one you put in there into the sample recreates the same issue I am having. So I guess I'm having some kind of threading problem? Not giving enough sleep time inbetween calls to the SFML audio components?

So you mean that you call Stop() right after Play()?
Anyway, calling play/stop/play without any delay (ie. commenting the sf::Sleep call) still works for me.

Should I be putting sf::sleep calls in my mainloop for each music file that is playing?

No, it should work fine under all circumstances. If there's any issue related to multi-threading, then it's a bug in SFML

Putting a Play(), sleep(2), stop(), play(), sleep(2), in my code, is giving me a similar thing as before, where it starts playing, stops, and then doesn't play again on the second play(). Any tips?

Hum? Isn't it the exact same thing that I did?

Yeah, before I was just calling them one after another, I thought they automatically took care of all the threading/timing stuff (and there's nothing on the tutorial page about using sf::sleep that I saw).

I modified the sample code to recreate what I was experiencing:

Code: [Select]

void PlayMusic()
{
    // Load an ogg music file
    sf::Music Music;
    if (!Music.OpenFromFile("lepidoptera.ogg"))
        return;

    // Display music informations
    std::cout << "lepidoptera.ogg :" << std::endl;
    std::cout << " " << Music.GetDuration()      << " sec"           << std::endl;
    std::cout << " " << Music.GetSampleRate()    << " samples / sec" << std::endl;
    std::cout << " " << Music.GetChannelsCount() << " channels"      << std::endl;

    // Play it
    Music.Play();
sf::Sleep(2);
Music.Stop();
    Music.Play();
    sf::Sleep(2);

    // Loop while the music is playing
    while (Music.GetStatus() == sf::Music::Playing)
    {
// I don't have this loop of waiting while playing in my code, so commenting out below is more in line
// with what I am doing (even though I probably should be using it I guess now)

        // Leave some CPU time for other processes
        //sf::Sleep(0.1f);

        // Display the playing position
        std::cout << "\rPlaying... " << std::fixed << std::setprecision(2) << Music.GetPlayingOffset() << " sec   ";
    }
    std::cout << std::endl;
}

Doing this has it play for a few seconds, stop, and then nothing comes out of the speakers after that.

I'm probably the one doing something wrong here I imagine.  I can understand the initial sleep call after play I guess, but is the loop of sleep calls necessary, or only for this sample?

[Laurent]

Still works for me.

But wait. My first modification works for you, but yours, where you add a sf::Sleep(2) after the second play, doesn't work anymore?? I'm lost :shock:

Regarding the sf::Sleep calls, you don't need them at all in a real program, it's just like this in the sample to let the program live as long as the music is playing.

[alaterale]

Still works for me.

But wait. My first modification works for you, but yours, where you add a sf::Sleep(2) after the second play, doesn't work anymore?? I'm lost :shock:

Regarding the sf::Sleep calls, you don't need them at all in a real program, it's just like this in the sample to let the program live as long as the music is playing.

Nevermind, my bad, I misspoke when I said the first example you gave me with Sound.cpp didn't have the bug.  I just went back to that again and I get the same thing  I think it was because originally I didn't know how long the real track was and that I heard anything at all made me think it works  Then I heard the full thing and did the later modifications on my own.  But yeah, I get the same result, it starts, stops, and then never starts playing again.

Ok, good to know about the sleep commands.  Then maybe there's something else going on here.....

[Laurent]

Ok

So, I come back to my first suggestions:

Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.

You can also send me an example compiled on your machine, so that we can make sure that it's not a an external DLL that is conflicting.

[alaterale]

Ok

So, I come back to my first suggestions:

Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.

You can also send me an example compiled on your machine, so that we can make sure that it's not a an external DLL that is conflicting.

Well I'm pretty sure its not make clean, as I've done that a lot.  I'll do it again though and see.  I'll upload my compiled exe to a filehosting site in a bit and put a link here.

[alaterale]

I think I solved the problem  I'm pretty sure now it was the OpenAL dll I was using, which is odd but whatever.  I substituted the openal32.dll file that is distributed with SFML-svn, and viola, it started playing like expected on the sample code.

I guess the official OpenAL dll is experiencing some technical difficulties.

I will try this on my own game and see if fixes the bug there too.

EDIT: Hooray!  It indeed works now fine in my own game  So it was just the OpenAL dll all this time, man I feel like an idiot now  Sorry for taking up so much of your time on this, I really appreciate all the help though!

[Laurent]

I'm glad you solved this problem