Max 8.1.3 crashes when using FlexASIO

[aleksati]

I`ve been experiencing some quite consistent crashes when using the FlexASIO driver in Max MSP. I'm on a Windows 10 HOME machine currently running these standard driver settings:

backend = "Windows WASAPI"
bufferSizeSamples = 512

[input]
suggestedLatencySeconds = 0.0
wasapiExclusiveMode = false

[output]
suggestedLatencySeconds = 0.0
wasapiExclusiveMode = false

The crashes happen when either video or audio is activated, but mostly with video. Might be some incompatibilities between FlexASIO and Max's video and audio engine.. or something. Don't know if this is related to other issues, but please tag them here if relevant.

[dechamps]

There's also #66 about Max MSP but I think yours is a different issue - you're not using an exclusive backend and your symptoms are different.

When you say "crash", what do you mean exactly? A return to desktop? An error message?

Can you enable logging, wait for it to crash, and then provide the log? This would help shed some light on the problem.

[aleksati]

Yes. I have a video processing patch that loads a video and does some processing. Max works fine until I upload a video, then the blue windows wheel starts turning for about 3 sec, then Max simply quits(ends task). That's what I mean when I say "it crashes". The program basically just shuts down. I`ve noticed the same thing when using audio, although not as frequent.

I will try to provide the log asap.

[aleksati]

Hope this is helpful!
FlexASIO.log

[dechamps]

I took a look at the log, and this is yet another case of Max MSP using the ASIO API in awkward (and arguably invalid) ways:

2020-04-24T12:06:53.2765682+02:00 15900 7420 --- EXITING CONTEXT: stop() [OK]
2020-04-24T12:07:04.4806096+02:00 15900 7420 --- ENTERING CONTEXT: CFlexASIO()

There's no call to ~CFlexASIO() which likely means Max MSP did not call ASIOExit() (or equivalent) before calling ASIOInit() again. FlexASIO does not handle that well, and is likely crashing as a result.

The ASIO SDK documentation does not explicitly say that the host application has to call ASIOExit() before calling ASIOInit(), but that's heavily implied (especially considering the state machine described in section (II)(2)).

The reason why it works with other drivers is, either these other drivers are written in such a way that this just happens to work (which is quite likely), or they know about the possibility of host applications acting strangely in that way and deploy countermeasures to make it work (e.g. by automatically calling ASIOExit() if the application does not do it).

Such counter-measures can be deployed in FlexASIO. I can look into that when I resume work on this project. I don't know when that'll be.

In the mean time you might want to inform the Max MSP developers that they're missing a call to ASIOExit() which compromises compatibility with ASIO drivers.

[aleksati]

I see! Cool. I hope you can manage. However, I just reported this to the Cycling 74 team (Max developers). Hopefully, they can manage to make a fix for it. I`ll post here in the future if they do. Thanks!

[dechamps]

Thanks! If you manage to start a conversation with them you might also want to point them at #66 which is another instance of… "interesting" behaviour that has been observed with Max.

[aleksati]

Got a response from the Max 8 developer team:

" Hi Aleksander,

I just tested this on my windows 10 home system and was able to reproduce. I've ticketed this for our engineers, though I can't guarantee it will get addressed as we already support ASIO4All as a universal ASIO driver and do not explicitly support WASAPI. I would recommend using ASIO4All for now to make sure you can keep moving forward. I will let you know what I hear back.

Best,"

So we`ll see in the upcoming updates I guess.

[dechamps]

They are missing the point. This has nothing to do with WASAPI (or even FlexASIO specifically), it has to do with them misusing the ASIO API in general. Hopefully they can get this to someone who can cleanly fix the issue.

[aleksati]

@dechamps , hello again! Apparently, in their latest update Max 8.1.4, they've listened and fixed this issue. I haven't tested it yet but I will later today. Ill give an update.

"• VIDDLL: Fixed crash when using FlexASIO and VIDDLL"

https://cycling74.com/forums/max-8-1-4-released

[dechamps]

I just attempted to reproduce with Max 8.1.5 and was unable to. Max now appears to properly uninitialize the ASIO driver when changing output modes or exiting.