Trouble with sf::Sound

[BruceJohnJennerLawso]

Im trying to set up my program so that it will play a small ogg file through a function as follows:

void Timer_Alarm()
{       sf::SoundBuffer buffer;
        if (!buffer.loadFromFile("C:\\Users\\Development\\Documents\\Visual Studio 2010\\Projects\\Countdown\\Release\\Countdown\\Audio\\ElapsedTimer.ogg"))
        {       Cmd_dashdash::Newline();
                Cmd_dashdash::Print_line("Unable to Load Audio");
        }
        else
        {       sf::Sound output;
                output.setBuffer(buffer);
                output.play();
                Cmd_dashdash::Print_line("Able to Load Audio");
        }
}

The perplexing thing is that the program gives me the "Able to load Audio" feedback, but never plays the sound. (and yes, I do have the volume on  )

The ogg file otherwise seems fine, but I did create it in audacity. Is it possible that there might be some issue with the way it was created?

[zsbzsb]

http://www.sfml-dev.org/tutorials/2.1/audio-sounds.php#common-mistakes

[BruceJohnJennerLawso]

So where is the scope of the buffer being lost? Is the whole function running through before the sound can finish playing?

[zsbzsb]

Maybe you should do some reading on how C++ handles scope 

void Timer_Alarm()
{       sf::SoundBuffer buffer; // create buffer in the scope of Timer_Alarm()
       
} // buffer destroyed....

[BruceJohnJennerLawso]

I understand scope, it just wasn't clear how the function itself was working. The windows API function for PlaySound seemed to stop the program while the sound played, which play() does not seem to.

[zsbzsb]

Sounds (and musics) are played in a separate thread. This means that you can do what you want after calling play() (except destroying the sound or its data, of course), the sound will continue to play until it's finished or stopped explicitly.

from the above link (and yes it is in red).....

[BruceJohnJennerLawso]

Ahh, okay I see.

It also appears that the sound stops playing when the sf::Sound object goes out of scope, even if that play() thread has been started.

Thanks for the help.

[zsbzsb]

Yes, and your sound buffer is also going out of scope 

[BruceJohnJennerLawso]

Yes, in the original code it was, but the sound wont play if the sf::Sound goes out of scope, even if the sound buffer has not been lost.

And... Part 2 (and believe me, nobody was dreading a part 2 more than me  )

The buffer and sf::Sound objects are now safely tucked away elsewhere

void Timer_Alarm()
{       //Alarm::Play_path = "ElapsedTimer.ogg";
        if (!Alarm::buffer.loadFromFile(Cmd_dashdash::Get_directory().append("\\Countdown\\Audio\\").append(Alarm::Play_path)))
        {       Cmd_dashdash::Newline();
                Cmd_dashdash::Print_line("Unable to Load Audio");
        }
        else
        {       Alarm::output.setVolume(100);
                Alarm::output.setBuffer(Alarm::buffer);
                Cmd_dashdash::Print_line("Able to Load Audio");
                Alarm::output.play();
        }
}

But the goal here is for the file path in question to be modifyable without recompiling the program. Alarm::Play_path is a string that is set to the appropriate file name earlier in the code by loading from a text file. If I uncomment that first line setting it to "ElapsedTimer.ogg", the program works fine, but if not, buffer.loadFromFile() rejects the file path & says that the file cannot be loaded. The file paths look absolutely identical to me, and I have double checked the value in the text file multiple times. What could possibly make it behave this way?

[dabbertorres]

First off, you should use '/' instead of "\\", it's portable.

Second, what are the values of Cmd_dashdash::Get_directory() and Alarm::Play_path?

Also, look into using relative paths rather than full paths.
For example, if your executable is in "C:/Users/Development/Documents/Visual Studio 2010/Projects/Countdown/Release", replace it with:
"./Countdown/Audio/ElapsedTimer.ogg"

'.' stands for current directory. That would allow for the program to work on other computers without having to edit for directories.

[BruceJohnJennerLawso]

Oh thanks, had no idea about the backslash thing. How will the compiler distinguish it from escape codes?

ie "Directory/new_directory"

or similar?

I did solve the problem though: by checking the size of the Alarm::Play_path string, I found that it was coming up one character too long. It turns out that the "newline" character was hiding in the string (invisible to printing on the console), which was screwing up the loadFromFile call.

Thanks for the note about ./ I think it will be very useful.

[zsbzsb]

Oh thanks, had no idea about the backslash thing. How will the compiler distinguish it from escape codes?

A "/" does not indicate any escape codes. The only reason you have to write "\\" is so that no characters are escaped (the end result will be a single "\" character). Therefore a single "/" works just fine. 

[dabbertorres]

Yep!

And good, glad you solved it!

And to add on to '.', ".." equals the parent directory. You can use those to get relative paths to anywhere on the system.

You can chain them together as well (ie: "../../.."). Try working around on a terminal/command prompt, you'll get the hang of it quick.

[BruceJohnJennerLawso]

Are the ./ and ../ tricks platform independent?

[Jesper Juhl]

Are the ./ and ../ tricks platform independent?

I wouldn't call them "tricks" but yes, "." refers to the current directory and ".." to the parent directory on all relevant platforms, just as "/" works as a path separator on all relevant platforms (unlike "\").