WASAPI device very frequently crashing on closeAudioDevice()


#1

We’re building a JUCE app and when using WASAPI the app frequently crashes when closing the audio device.
Here is the relevant stack:

TestApp.exe!juce::ComSmartPtr<juce::WasapiClasses::WASAPIDeviceBase::SessionEventCallback>::release() Line 121	C++
TestApp.exe!juce::ComSmartPtr<juce::WasapiClasses::WASAPIDeviceBase::SessionEventCallback>::operator=(juce::WasapiClasses::WASAPIDeviceBase::SessionEventCallback * const newP) Line 82	C++
TestApp.exe!juce::WasapiClasses::WASAPIDeviceBase::deleteSessionEventCallback() Line 555	C++
TestApp.exe!juce::WasapiClasses::WASAPIDeviceBase::closeClient() Line 476	C++
TestApp.exe!juce::WasapiClasses::WASAPIInputDevice::close() Line 717	C++
TestApp.exe!juce::WasapiClasses::WASAPIAudioIODevice::close() Line 1166	C++
TestApp.exe!juce::WasapiClasses::WASAPIAudioIODevice::~WASAPIAudioIODevice() Line 992	C++
[External Code]	
TestApp.exe!juce::ContainerDeletePolicy<juce::AudioIODevice>::destroy(juce::AudioIODevice * object) Line 51	C++
TestApp.exe!juce::ScopedPointer<juce::AudioIODevice>::operator=(juce::AudioIODevice * const newObjectToTakePossessionOf) Line 142	C++

TestApp.exe!juce::AudioDeviceManager::closeAudioDevice() Line 595 C++

The crash occurs when releasing the sessionEventCallback. The IAudioSessionEvents pointer is a dead pointer here so I suspect that there is some order of termination problem somewhere in the JUCE WASAPI implementation. Possibly IAudioSessionEvents is not being unregistered early enough in the shutdown sequence.

This crash occurs frequently so it would be good if it can be fixed.


#2

That’s quite odd! Can’t say I’ve ever encountered that one even with the host I’m writing now, and the WASAPI code hasn’t changed much over the years…

Is just switching driver often sufficient for you to see this, or are there other steps you can provide that demonstrate this consistently with the plugin host or demo? Or would you be able to write some small test?


#3

The problem occurs only when shutting down the device. This happens when we close the app or when some operation occurs that requires us to shutdown the audio device. The crash is intermittent though quite frequent - so far I don’t have a reproducible recipe. The demo doesn’t close the device so frequently so it would be less likely to show up there unfortunately.


#4

I have the same problem.
It happens randomly. Every now and then, when I shut down the my application, the WASAPI device crashes.


#5

That’s exactly the same issue. I bet if you look at the stack you will see its crashing when releasing the SessionEventCallback


#6

Yes, I seem to remember seeing something about the SessionEventCallback. I’ll check the stack next time it happens.


#7

Could you please provide a simple way to reproduce this?

I modified AudioAppExample to use WASAPI only and made the following changes

class MainContentComponent   : public AudioAppComponent,
                               public Timer
{
public:
    void timerCallback() override
    {
        if (deviceManager.getCurrentAudioDevice() != nullptr)
            shutdownAudio();
        else
            setAudioChannels (0, 2);
    }

    //==============================================================================
    MainContentComponent()
        : phase (0.0f),
          phaseDelta (0.0f),
          frequency (5000.0f),
          amplitude (0.2f),
          sampleRate (0.0),
          expectedSamplesPerBlock (0)
    {
        setSize (800, 600);

        startTimerHz (3);
    }

so that it is continually opening and closing the audio device, but I’m not seeing a crash. Any suggestions?


#8

I’ll give it a try and let you know if I can repro that way.

BTW are you running an up to date Windows 10? This may even be OS dependent. WASAPI shared mode is very picky about the order of operations in which it is initialized. Even other applications using Windows can affect the behavior making it harder to debug things like this. I’ll let you know if I can repro with your test however.