imitone community

Valis

Member

Registered: 2021-12-07

Scope PCI cards - portaudio causes bsod

My Scope system is rather legacy, but I know this particular issue also affects Sonic|Core's current Scope offering, which is the Xite box.  The driver architecture is shared to a large degree, and there are 64bit issues.  I generated and sent two crash reports, the second because I forgot to provide my email address with the first.

Submitted the second report with my registered (to the app, not the forums) email address.

Evan

developer

From: Olympic Peninsula, WA

Registered: 2014-05-23

Website

Re: Scope PCI cards - portaudio causes bsod

Saw your logs.  This is an unusual one.  Do you have issues with Audacity (which also uses PortAudio) ?

We designed recent versions of our software to detect crashes — even blue-screen errors! — that happen while specific audio backends are being accessed.  If the app crashes during that interval of time, it registers a “trauma” and will refuse to use that audio backend at all in the future.

In your case, the log stops abruptly when the app starts running but I don’t see any sign in these logs that it got as far as audio initialization.  That said, logs can cut off “early” if a bluescreen happens.

Some things to try:

Update your graphics drivers or install imitone with our graphics workaround selected (rules out another possible BSOD cause)
View the data in the error report and look for a file called “app_trauma.txt” in the app’s data folder.

If you’re really convinced it’s your audio drivers, I’ve hand-written an app_trauma file which you can drop into your data folder to suppress all audio backends except ASIO:

Download the file : https://imitone.com/support/disable/win … trauma.txt

com.interactopia.imitone	0.11.0	portaudio.mme	
com.interactopia.imitone	0.11.0	portaudio.directsound	
com.interactopia.imitone	0.11.0	portaudio.wasapi	
com.interactopia.imitone	0.11.0	portaudio.wdm-ks	

Valis

Member

Registered: 2021-12-07

Re: Scope PCI cards - portaudio causes bsod

Portaudio is a known conflict with the Scope cards, you should see that in the email.  I'll try the trauma app next, but if memory serves you can do this in the installer, correct?

Scope's ASIO driver has some issue with 64bit addressing which didn't crop up until more recent versions of portaudio_x64.dll, which is known because other devs use this library.  With Plogue Bidule for instance, once he integrated the trunk directly (instead of linking the dll) the crashes are unavoidable. Before that, he was using only v1.9.0.9 of the dll and that version works fine (with my Scope cards).  Interestingly, your version of this dll has no version info in the properties panel > details pane.

I do not expect you can fix this, but I have a relationship with this vendor and would love to find any and all resources and information I can send them to help fix this error, so thank you for your help.  Will report back on this issue soon...

Valis

Member

Registered: 2021-12-07

Re: Scope PCI cards - portaudio causes bsod

Trauma.txt gave the same result as setting only ASIO during install, BSOD as soon as the key is entered (clearly the key is never saved because the audio engine is started immediately after, and I am able to run the app each time and get the key screen again).

Evan

developer

From: Olympic Peninsula, WA

Registered: 2014-05-23

Website

Re: Scope PCI cards - portaudio causes bsod

Oh — it's the ASIO driver, not the Windows ones?  In that case, you'll want an app_trauma.txt that disables ASIO and leaves the other APIs intact.  Like this:

```
com.interactopia.imitone    0.11.0    portaudio.asio   

```

You might be able to make do with kernel streaming (called "low-latency" in the latest build).

imitone for Windows relies on some PortAudio extensions for improved ASIO functionality; this means that unfortunately, you can't simply swap in a replacement portaudio_x64.dll.

Valis

Member

Registered: 2021-12-07

Re: Scope PCI cards - portaudio causes bsod

I didn't expect that to work with Bidule either, but since it's the same codebase it made sense that he didn't change enough to cause any issues I could see.  I was however comparing to your build to see if there is some change in the code trunk that affects Scope that I can feed back to the developer.

At this point the Scope platform is maintained by the company owner, and he has access to a former employee when necessary.  But I am trying to build a case for the community to support him in hiring someone to fix these issues, if it was simple for him it would have been done by now.