playing sounds simultaneously

[Reborn]

Hey,
I was looking for a good way to play sounds simultaneously with SFML.
After googeling I found a post from nexus (http://en.sfml-dev.org/forums/index.php?topic=6697.0). He only gave a hint: Push the playing sounds into a queue and pop them if they reached the status sf::Sound::Status::Stopped.
I thought, that's a good idea, so I tryed to programm a general solution to this problem:

(click to show/hide)

#include "stdafx.h"
class SoundManager
{
private:
        using lock_t = std::lock_guard<std::mutex>;

public:
        SoundManager();
        ~SoundManager();
        void registerSound(const sound_id_t id, const sf::SoundBuffer& sound_buffer);
        void play(const sound_id_t id);

private:
        void th_worker();

        std::atomic<bool> m_Running;
        std::mutex m_Mutex;
        std::map<sound_id_t, std::tuple<sf::Sound, std::queue<sf::Sound>>> m_ListSounds;
        // m_Thread have to be the last member (because only that way it can be secured that
        // th_worker gets executed after the SoundManager initilizer has initialized all his members)
        std::thread m_Thread;
};

(click to show/hide)

#include "SoundManager.h"

SoundManager::SoundManager()
        : m_Running(true)
        , m_Thread(std::bind(&SoundManager::th_worker, this))
{
}
SoundManager::~SoundManager()
{
        m_Running = false;
        m_Thread.join();
}
void SoundManager::th_worker()
{
        while (m_Running)
        {
                {
                        lock_t lock(m_Mutex);
                        for (auto& tuple_sound : m_ListSounds)
                        {
                                auto& queue_sound = std::get<1>(tuple_sound.second);
                                if (!queue_sound.empty())
                                {
                                        if (queue_sound.front().getStatus() == sf::Sound::Status::Stopped)
                                        {
                                                queue_sound.pop();
                                        }
                                }
                        }
                }
                std::this_thread::sleep_for(std::chrono::milliseconds(1));
        }
}
void SoundManager::registerSound(const sound_id_t id, const sf::SoundBuffer& sound_buffer)
{
        m_ListSounds.insert
        (
                std::make_pair
                (
                        id,
                        std::make_tuple
                        (
                                sf::Sound
                                (
                                        sound_buffer
                                ),
                                std::queue<sf::Sound>()
                        )
                )
        );
}
void SoundManager::play(const sound_id_t id)
{
        lock_t lock(m_Mutex);
        auto& iter = m_ListSounds.find(id);
        assert(iter != m_ListSounds.end());
        auto& queue_sounds = std::get<1>(iter->second);
        queue_sounds.push(std::get<0>(iter->second));
        queue_sounds.back().play();
}

Everything is working fine and anyone can feel free to use it.
The thing I want to know is, what do you think about this solution? May be there are some better out there?

regards

Julian

[Hapax]

Why does this use a thread? The manager can be updated whenever any function is called (such as "play new sound" or explicitly "update") at which point, all the ended sounds can be popped at once.

I mean, it might work fine and everything and that's great; I just think that adding the extra complexity of using a thread is not necessary here.

[Reborn]

Thank you for your post.

Is it established practice to do it like you suggested?
I mean, it's like let clean up the gabrage of anyone's work from anyone else.

[Hapax]

I would say everyone can approach tasks in their own way and often do so I don't think there's only one way ("established practice") to do this.

I was merely questioning if the extra thread is required here when you can achieve a similar result without it.

[JayhawkZombie]

SFML sounds are played in a different thread internally, so you don't have to put it in another thread yourself.  Whenever you register a sound, you can check for ones that finished at that time. Sleeping for only 1ms then looping through will eat up CPU time. Even though it's in a different thread it's still associated with your process and could be scheduled less often if the OS thinks you're eating up too much time.

I think that's what Hapax is getting at.

Like Hapax said, you could periodically call "Update" on your manager (maybe every few seconds) so it can flush finished audio. It would loop through its container less often, thus eating up less CPU time.
Or you could have it running in another thread if you're worried about hitching and use a condition variable to wake up on command.  Just another idea.  No read right/wrong here.

[Reborn]

That is what I was looking for. Some other views of the same point. Thank you.