AudioTransportSource stop - source of long pauses

General JUCE discussion
1

This isn’t the most friendly of the features of AudioTransportSource. How about it sets playing=false, returns immediately and starts a timer to send the change message later?

void AudioTransportSource::stop()
{
    if (playing)
    {
        {
            const ScopedLock sl (callbackLock);
            playing = false;
        }

        int n = 500;
        while (--n >= 0 && ! stopped)
            Thread::sleep (2);

        sendChangeMessage();
    }
}
1 Like
2

Since sendChangeMessage() already calls listeners asynchronously, I wonder if there is any harm in doing something like:

        std::thread{ [&](){ transport.stop(); } }.detach();

In the caller if a non-blocking stop is needed?

3

Detaching threads is a bad idea…
Also, though probably ok, the way you’ve written that, transport could be dangling or in the middle of destruction etc. whilst it’s being called.

All seems a but error prone to me.

2 Likes
4

Good points… Thinking it through, even if the AudioTransportSource were allocated on the stack for the lifetime of the program (which is my use case), we could still end up in the scenario you describe.

@jimc’s proposal is clearly preferred.

Does anyone on the JUCE team have thoughts about incorporating this change?