Pro Tools Initialization

[drbdt]

Pro Tools v 2019.6.0 is unable to initialize FlexASIO as playback engine. Please advise.

[dechamps]

Sorry to hear that. Can you follow the procedure to obtain a log and provide the log here? This will provide more information to help troubleshoot the problem.

[drbdt]

Thank you for the quick response! It appears that since FlexASIO will not initialize it cannot begin logging to the file.

[dechamps]

Oh. Are you using the latest FlexASIO version (1.5)? Can you describe exactly what happens? Do you get an error message?

[drbdt]

Yes, I am using v 1.5- Pro Tools returns an error that reads "The selected audio device could not be initialized. Please choose another audio device" during initial startup or when FlexASIO is selected in the playback engine menu.

[dechamps]

Is this specific to Pro Tools? Have you tried using FlexASIO with any other ASIO application?

[drbdt]

It appears to be working in REAPER. I did manage to generate a log.
FlexASIO.log

[dechamps]

Thanks, the log gave me the information I need. I suspect the problem is that Pro Tools is requesting a buffer size that's too small:

2019-07-17T11:24:24.2694749-04:00 15044 2244 Request to create buffers for 4 channels, size 256 samples

256 samples at 44.1 kHz is 5.8 ms, plus a PortAudio additional "suggested latency" buffer of 17.4 ms, makes for a total host buffer of 23.2 ms. There is a known issue where DirectSound, the default FlexASIO backend, cannot handle buffer sizes that small on the input side, and gets stuck instead of streaming buffers. And indeed buffer switches do not occur, and Pro Tools seems to give up after about 15 seconds:

2019-07-17T11:24:24.4051323-04:00 15044 2244 --- EXITING CONTEXT: start() [OK]
2019-07-17T11:24:39.4914899-04:00 15044 2244 --- ENTERING CONTEXT: stop()

There's shared blame between FlexASIO and Pro Tools here. On the one hand, FlexASIO is advertising a minimum buffer size of 44 samples that it obviously cannot support in practice:

2019-07-17T11:24:24.2693514-04:00 15044 2244 --- ENTERING CONTEXT: getBufferSize()
2019-07-17T11:24:24.2693747-04:00 15044 2244 Calculating default buffer size based on 44100 Hz sample rate
2019-07-17T11:24:24.2694003-04:00 15044 2244 Returning: min buffer size 44, max buffer size 44100, preferred buffer size 882, granularity 1

On the other hand, if Pro Tools followed the suggested buffer size (882 samples) instead of arbitrarily choosing a 256-sample buffer size, we wouldn't have this problem.

To fix your problem, you should choose a larger buffer size in the Pro Tools settings. If Pro Tools does not allow you to change the ASIO buffer size, then you can force it using the bufferSizeSamples FlexASIO configuration option. I would suggest 882 as a starting point.

If you do want to use a smaller buffer size, then you should use a different backend that is more likely to work with smaller buffer sizes, such as WASAPI or WDM-KS. Note, however, that 5.6 ms is a really small buffer size, which is quite likely to cause problems no matter what backend you use, especially in full duplex (i.e. both input and output) operation.

I will update the documentation to mention that small buffer sizes can cause problems (besides glitches), and perhaps change the minimum buffer size that FlexASIO reports to try to mitigate this problem.

[dechamps]

FlexASIO 1.6 now advertises a higher minimum buffer size when using a DirectSound input to prevent applications from triggering this issue.