WASAPIOutputDevice::getNumSamplesAvailableToCopy crashes with nullptr

    int getNumSamplesAvailableToCopy() const
        if (numChannels <= 0)
            return 0;

        if (! useExclusiveMode)
            UINT32 padding = 0;

            if (check (client->GetCurrentPadding (&padding)))
                return actualBufferSize - (int) padding;

        return actualBufferSize;

client is nullptr.

|>|[Inline Frame] Waveform 10 (64-bit).exe!juce::WasapiClasses::WASAPIOutputDevice::getNumSamplesAvailableToCopy() Line 910|C++|
| |Waveform 10 (64-bit).exe!juce::WasapiClasses::WASAPIOutputDevice::copyBuffers(const float * * srcBuffers, int numSrcBuffers, int bufferSize, juce::WasapiClasses::WASAPIInputDevice * inputDevice, juce::Thread & thread) Line 932|C++|
| |Waveform 10 (64-bit).exe!juce::WasapiClasses::WASAPIAudioIODevice::run() Line 1291|C++|
| |Waveform 10 (64-bit).exe!juce::Thread::threadEntryPoint() Line 96|C++|
| |[Inline Frame] Waveform 10 (64-bit).exe!juce::juce_threadEntryPoint(void *) Line 118|C++|

Maybe this needs a CriticalSection around it?

                // Recreate client
                client = nullptr;
                client = createClient();

How about if the method just checks whether the client is null -

int getNumSamplesAvailableToCopy() const
    if (numChannels <= 0 || client == nullptr)
        return 0;


does that fix the crash that you’re seeing?

I haven’t been able to reproduce this yet, just seeing it in crash logs from users. I’ll spend a bit more time trying to reproduce and let you know if that fixes it.

Hi G-Mon,

Have you had any luck in reproducing this? We see this popping up in our user’s crash log, but I haven’t been able to reproduce it yet.

Nope, but haven’t tried lately.

I’ve cherry-picked some wasapi-commits from the master branch (we were using 5.4.7), lets see what happens. I’ll report back if it solved it.