Pro Tools WASAPI AUDCLNT_E_DEVICE_IN_USE error

[Kurausukun]

I have a very similar problem to #69 where Pro Tools First will tell me "Pro Tools is unable to reacquire the hardware because it is in use by another application. Please quit other applications and hit "OK" to retry." I read through the previous issue and attempted to change my settings file so that I could avoid the issue, but even after changing the settings, I get the same error. I was hoping you could see whether this issue is something that Pro Tools is doing wrong that they would need to fix on their end, or if I can change my settings in a different way to work around the issue.

I was able to get a log file, which includes my settings, so I made a gist here.

Thank you for any help.

[dechamps]

Well that log is… interesting. It paints the following story:

At 03:54:28.341, FlexASIO is initialized, and is able to open an output stream just fine:

Checking if output supports this sample rate
CFlexASIO::OpenStream(inputEnabled = 0, outputEnabled = 1, sampleRate = 48000, framesPerBuffer = 0, callback = 00007FF9EEADB950, callbackUserData = 0000000000000000
Using shared mode for output WASAPI stream
Enabling auto-conversion for output WASAPI stream
Opening PortAudio stream with...
...input parameters: none
...output parameters: PortAudio stream parameters for device index 10, 2 channels, sample format 2147483652 [Int24, NonInterleaved], suggested latency 0s, host API specific: 56 bytes structure, type 13 [WASAPI], version 1, WASAPI specific: flags 68 [UseChannelMask], channel mask 1599 [Front Left, Front Right, Front Center, Low Frequency, Back Left, Back Right, Side Left, Side Right], host processor output 0000000000000000, host processor input 0000000000000000, thread priority 0 [None], stream category 0 [Other], stream option 0 [None]
...sample rate: 48000 Hz
...frames per buffer: 0
...stream flags: 8 [PrimeOutputBuffersUsingStreamCallback]
...stream callback: 00007FF9EEADB950 (user data 0000000000000000)
[PortAudio] WASAPI: IAudioClient2 set properties: IsOffload = 0, Category = 0, Options = 0
[PortAudio] wFormatTag     =WAVE_FORMAT_EXTENSIBLE
[PortAudio] SubFormat      =KSDATAFORMAT_SUBTYPE_PCM
[PortAudio] Samples.wValidBitsPerSample =24
[PortAudio] dwChannelMask  =0x63F
[PortAudio] nChannels      =2
[PortAudio] nSamplesPerSec =48000
[PortAudio] nAvgBytesPerSec=384000
[PortAudio] nBlockAlign    =8
[PortAudio] wBitsPerSample =32
[PortAudio] cbSize         =22
[PortAudio] WASAPI::OpenStream(output): framesPerUser[ 480 ] framesPerHost[ 1056 ] latency[ 22.00ms ] exclusive[ NO ] wow64_fix[ NO ] mode[ POLL ]
PortAudio stream opened: 00000000483389B0
Stream info: PortAudio stream info version 0, input latency 0s, output latency 0.022s, sample rate 48000 Hz
Closing PortAudio stream 00000000483389B0
Output supports this sample rate
Sample rate 48000 is available

So far so good. At 03:54:28.539, for some reason, Pro Tools decides to close FlexASIO and reinitializes it about 1 second later:

2020-08-16T03:54:28.5398069-04:00 21256 21028 --- ENTERING CONTEXT: ~CFlexASIO()
2020-08-16T03:54:28.5398327-04:00 21256 21028 --- EXITING CONTEXT: ~CFlexASIO() [OK]
2020-08-16T03:54:28.5398512-04:00 21256 21028 Terminating PortAudio
2020-08-16T03:54:28.5398706-04:00 21256 21028 [PortAudio] TerminateHostApis in
2020-08-16T03:54:28.5399187-04:00 21256 21028 [PortAudio] TerminateHostApis out
2020-08-16T03:54:28.5399373-04:00 21256 21028 PortAudio terminated successfully
2020-08-16T03:54:28.5399543-04:00 21256 21028 [PortAudio] Disabling PortAudio debug output redirection
2020-08-16T03:54:29.5935859-04:00 21256 21028 --- ENTERING CONTEXT: CFlexASIO()
2020-08-16T03:54:29.5936265-04:00 21256 21028 --- EXITING CONTEXT: CFlexASIO() [OK]

Okay, why not. But then, from that point on, FlexASIO is unable to open the output anymore, failing with a AUDCLNT_E_DEVICE_IN_USE error:

Checking if output supports this sample rate
CFlexASIO::OpenStream(inputEnabled = 0, outputEnabled = 1, sampleRate = 48000, framesPerBuffer = 0, callback = 00007FF9EEADB950, callbackUserData = 0000000000000000
Using shared mode for output WASAPI stream
Enabling auto-conversion for output WASAPI stream
Opening PortAudio stream with...
...input parameters: none
...output parameters: PortAudio stream parameters for device index 10, 2 channels, sample format 2147483652 [Int24, NonInterleaved], suggested latency 0s, host API specific: 56 bytes structure, type 13 [WASAPI], version 1, WASAPI specific: flags 68 [UseChannelMask], channel mask 1599 [Front Left, Front Right, Front Center, Low Frequency, Back Left, Back Right, Side Left, Side Right], host processor output 0000000000000000, host processor input 0000000000000000, thread priority 0 [None], stream category 0 [Other], stream option 0 [None]
...sample rate: 48000 Hz
...frames per buffer: 0
...stream flags: 8 [PrimeOutputBuffersUsingStreamCallback]
...stream callback: 00007FF9EEADB950 (user data 0000000000000000)
[PortAudio] WASAPI: IAudioClient2 set properties: IsOffload = 0, Category = 0, Options = 0
[PortAudio] WASAPI ERROR HRESULT: 0x8889000A : AUDCLNT_E_DEVICE_IN_USE
FILE: C:\Users\edechamps\Documents\FlexASIO\src\portaudio\src\hostapi\wasapi\pa_win_wasapi.c {LINE: 3330}]
[PortAudio] WASAPI ERROR PAERROR: -9996 : Invalid device
FILE: C:\Users\edechamps\Documents\FlexASIO\src\portaudio\src\hostapi\wasapi\pa_win_wasapi.c {LINE: 3364}]
[PortAudio] WASAPI ERROR PAERROR: -9996 : Invalid device
FILE: C:\Users\edechamps\Documents\FlexASIO\src\portaudio\src\hostapi\wasapi\pa_win_wasapi.c {LINE: 3761}]
Output does not support this sample rate: unable to open PortAudio stream: Invalid device
Sample rate 48000 is unavailable

That's… strange. Off the top of my head I can see a couple of hypotheses:

1. There's a bug in FlexASIO that is triggered when FlexASIO is initialized more than once in a given process. That seems unlikely to me because it seems implausible that this would lead to this specific AUDCLNT_E_DEVICE_IN_USE error.
2. Something changed after FlexASIO was first closed that made the device unusable for the second instance of FlexASIO.

The reason why I suspect it might be (2) is because I have a suspicion that this "unload, then load again" behaviour is caused by Pro Tools enumerating ASIO drivers on the system and loading them one after the other. The thing is, with some ASIO drivers, just the act of initializing them is enough to cause side effects that change the state of the hardware device. So, one hypothesis is that Pro Tools loaded a different ASIO driver between 03:54:28.539 and 03:54:29.593, and that ASIO driver messed up the state of the device, preventing FlexASIO from opening it again.

@Kurausukun Do you have other ASIO drivers installed? If so, can you try uninstalling them and see what happens? (You can also temporarily disable a driver by deleting its registry key under HKEY_LOCAL_MACHINE\SOFTWARE\ASIO, and restore it afterwards.)

Another hypothesis consistent with (2) is that Pro Tools itself is opening the device in exclusive mode, preventing FlexASIO from opening it. I'm not familiar with Pro Tools so I'm not sure if that could be the case.

[Kurausukun]

I do have two other ASIO drivers installed. I exported their keys for later and deleted them from my registry. Now when I open Pro Tools and select it, it doesn't give me that error, but Pro Tools itself crashes. I have a log of this as well. I also got a log from Pro Tools itself from when it crashed, but you said you aren't familiar with it, so I haven't uploaded it--if you want to try and parse it anyway, let me know and I can upload it.

[dechamps]

Thanks for the log. It looks like Pro Tools chokes on the first stream callback and never returns controls to FlexASIO:

2020-08-16T17:40:02.7094262-04:00 4304 11784 --- ENTERING STREAM CALLBACK
2020-08-16T17:40:02.7095057-04:00 4304 11784 Updated sample position: timestamp 5950503000000, 0 samples
2020-08-16T17:40:02.7095297-04:00 4304 11784 PortAudio stream callback with input 0000000034E2D040, output 0000000034E2CFA0, 2048 frames, time info (PortAudio stream callback time info with input buffer ADC time 5950.5, current time 5950.53, output buffer DAC time 5950.53), flags 0
2020-08-16T17:40:02.7095750-04:00 4304 11784 Transferring input buffers from PortAudio to ASIO buffer index #0
2020-08-16T17:40:02.7095972-04:00 4304 11784 Firing ASIO bufferSwitchTimeInfo() callback with buffer index: 0, time info: (ASIO time with reserved 0 0 0 0, time info (ASIO time info with speed 0, system time 5950503000000, sample position 0, sample rate 48000 Hz, flags 7 [kSystemTimeValid, kSamplePositionValid, kSampleRateValid], reserved 0 0 0 0 0 0 0 0 0 0 0 0), time code (ASIO time code with speed 0, samples 0, flags 0, future 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))
2020-08-16T17:40:02.7097171-04:00 4304 11784 --- ENTERING CONTEXT: outputReady()
2020-08-16T17:40:02.7097403-04:00 4304 11784 Host supports OutputReady
2020-08-16T17:40:02.7097678-04:00 4304 11784 --- EXITING CONTEXT: outputReady() [OK]
2020-08-16T17:40:03.0071095-04:00 4304 11784 Closing logfile

I don't think I've seen this before. Does that happen with the default configuration (i.e. no config file) too? If not, can you try to determine which one of the configuration options you're using is causing the crash? (I would start with the sampleType = "Int24" option, which makes me suspicious because that's not a well-tested setting, and it's consistent with a crash happening at buffer manipulation time.)

FlexASIO managed to log the closing of the logfile, which is eyebrow-raising because that means static destructors had a chance to run, which in turn means the DLL was cleanly unloaded. These things normally don't happen in the case of a hard crash. This might mean that Pro Tools is crashing in some kind of "graceful" way.

Feel free to upload a Pro Tools log. I'm not familiar with Pro Tools so I don't know if I'll be able to make sense of it, but I can give it a try. If you can provide both a FlexASIO log and a Pro Tools log that refer to the same crash, so that I can correlate timestamps between the two, that's even better.

[dechamps]

Oh and by the way, regarding the original issue:

I do have two other ASIO drivers installed. I exported their keys for later and deleted them from my registry. Now when I open Pro Tools and select it, it doesn't give me that error

This part looks suspiciously similar to #86, where other ASIO drivers (ASIO4ALL in the case of #86) mess up the initialization sequence of FlexASIO. Out of curiosity, would you mind naming the other two drivers you had installed?

[Kurausukun]

Yes--my other drivers are ASIO4ALL, which is the only thing that worked with it before, and another one called Realtek ASIO Driver that I'm pretty sure just came with my audio drivers--I've never gotten it to work before.

I tried running FlexASIO with no settings file and it actually worked--mostly. The audio was very clicky, which I am 99% sure is because whatever the default buffer is set to was too small. Also, the reason I set my audio as Int24 was because that's the setting I have my soundcard set to--24-bit 48kHz. But if it's causing crashes, I guess I don't have a choice.

I also was hoping to be able to use WASAPI instead of DirectSound, but I just tried to use it by making a settings file doing nothing but setting the backend to "Windows WASAPI" and setting exclusive mode to false, but while it does not crash the program, no audio can be heard. That is probably unrelated though, so I think there's no need to look into it immediately.

But at least for the original issue, it does appear that ASIO4ALL was causing the problem with the "hardware in use" issue, and if I can get this to work, I'd be fine to uninstall that completely anyway since this will give me a lot more options.

[dechamps]

the reason I set my audio as Int24 was because that's the setting I have my soundcard set to--24-bit 48kHz.

When operating in WASAPI shared mode (or any other shared backend), it doesn't make sense to change this setting from its default (32-bit float). That's because the audio gets processed by the Windows Audio Engine anyway which operates in 32-bit float. If you use a different sampleType, the Windows Audio Engine is just going to convert your samples to 32-bit float anyway behind the scenes. The conversion to your hardware configured sample type happens later, near the output of the Windows Audio Engine. The only case where using a custom sampleType makes sense is when using an exclusive backend such as WASAPI Exclusive or WDM-KS.

Anyway, filed separate issue #87 regarding the custom sample type crashing Pro Tools.

I just tried to use it by making a settings file doing nothing but setting the backend to "Windows WASAPI" and setting exclusive mode to false, but while it does not crash the program, no audio can be heard

This resembles symptoms seen in #83. Feel free to provide a log if you'd like me to take a look.

[Kurausukun]

Thanks for educating me regarding that, I obviously did not know the many layers the audio goes through before it is presented.

Anyway, I managed to get slightly better results as a result of switching my buffer size from 2048 to 256 in WASAPI shared, but it's still not perfect--while it doesn't sound choppy like DirectSound did, it cuts out for extended periods of time (think half a second-ish) randomly. Perhaps this can be resolved with other buffer settings, but I captured the log either way. Fair warning, it's large.

Edit: I was right, using a buffer of 512 seems to work perfectly so far.

[dechamps]

I am not able to reproduce the issue you're describing with a 256-sample buffer size. With FlexASIO 1.6 the following configuration seems to work fine in Pro Tools First 2019.6.0:

backend = "Windows WASAPI"
bufferSizeSamples = 256

Keep in mind that when using such small buffer sizes it is very important to disable logging (by deleting or renaming the logfile) during testing, as the logging itself slows down FlexASIO and can make it miss its deadlines. You can also take a look at the FAQ entry for other possible causes of glitches.

(By the way, I noticed a new issue where Pro Tools misbehaves when bufferSizeSamples is not specified - see #89. I don't think that's relevant here though.)

Closing as it's not clear to me there's anything left to do here, aside from the issues already tracked in #87 and #89.