I have seen this warning myself. However, as you mentioned in your original post, it used an additional thread. The fix for it, though, was to simply make sure that the thread had finished before destroying everything. Since sounds are played in their own thread automatically, I was making a possible connection.
However, sounds should be automatically stopped when they are destroyed so as long as the sound is destroyed before the sound buffer, it should be okay. I would probably create a small test by adding a loop that waits for all sounds to finish in the destructor but that's just me.
Adding the sound to its parent class could mean that it's getting created before the buffer. Try adding the buffer instead to the parent class.
In fact, since sound buffers are heavy resources, they should most likely not be stored with their sounds. More commonly, all the sound buffers are stored together in some form of resource manager. This could be a simple vector of sound buffers, for example, which would be stored in a high scope and pass around via reference or pointer when needed. Here's an example of what I mean:
class A
{
public:
A(sf::SoundBuffer& soundBuffer) : m_sound(soundBuffer) { }
play() { m_sound.play(); }
private:
sf::Sound m_sound;
}
int main()
{
sf::SoundBuffer soundBuffer; // sound buffer in scope of main function
A a(soundBuffer); // sound buffer passed to A class (its internal sound stores a pointer to the buffer)
a.play();
sf::sleep(sf::seconds(1.f));
a.play();
sf::sleep(sf::seconds(2.f));
a.play();
sf::sleep(sf::seconds(4.f));
}
You could add a method to change the soundBuffer of the sound as required.
It's starting to look like a direct wrapper for an sf::Sound
but hopefully I explained the idea.
