Using ASIO Link Pro to avoid SCOPE BSOD in Win 10

[malcolmbarr]

I recently built a Win10 pro 64 bit PC for the purposes of running 3 Pulsar 2 PCI cards and with the idea of also using it to take some of the VST instrument CPU load off my main PC running Cubase. Like many users here, I run into frequent BSOD errors when I try and run standalone versions of VST instruments and access the ASIO Scope driver.

garyb (whose help I value enormously!!) will interject that this problem is caused by poorly written apps which don't implement the ASIO protocol properly, while the SCOPE hardware is not a regular windows soundcard. Years ago, I tried to get garyb and FXPansion to work together to solve this with no success. Regardless of where the fault lies, users like me simply want a work around. I don't think I am alone in wanting to be able to run ASIO using apps outside of a DAW that works with the SCOPE ASIO driver. See my note at the end.

In my case of a brand new installation, Windows was also not able to access to Scope Wave devices properly for bog standard MME playback: it would list the Scope speakers devices in the sounds control panel but could not use them. Fortunately, this BSOD work around also solves this issue.

Using ASIO LINK PRO

The key problem solver here is ODEUS Asio Link Pro. I bought this software years ago, and then the producer of it unfortunately passed away. His nephew, who was passed the rights to the software, has blessed an effort by "Give Academy" to produce a patcher for the software which effectively makes it free to use. I am very grateful to all involved in providing this. The software and the patcher for it are available here:

https://give.academy/posts/2018/03/02/AsioLinkPro/

Please note: we are dealing with issues that can cause BSOD and consequent problems with Windows boot up, need for safe mode, etc. If you are not comfortable with that, do not proceed, and do so at your own risk.

My experience in getting this working runs as follows:

1. Get your scope hardware installed in the PC with drivers functioning properly, software activated, and ASIO source/destination modules in your project.

2. Install the ASIO LINK PRO software (I find it helpful to check the box which states "install 16 stereo WDM devices). Then run the patcher for both the 32bit and 64 bit versions.

3. With Scope 7 running, open the ASIO LINK PRO TOOL 32 - DO NOT run the 64 bit version (simply labelled ASIO LINK PRO TOOL with no number to follow) as it will cause a BSOD listing ScopePCI.sys as the problem.

4. Press START ASIO in the ASIO LINK PRO 32 Tool. The link pro window should pop up. Above the words G.A. COLLECTIVE 2018 near the top centre of this window, make sure it lists ASIO SCOPE as the device it is using. If not, click on "pick driver" and select it. Then ensure that "Enable multi-clients" is green (click it if red).

5. Open an application with which you want to use the SCOPE audio hardware. DO NOT select ASIO SCOPE as the audio hardware device in the apps setting (you are at risk of BSOD if you do). Instead, select ASIO LINK PRO as the audio driver. Doing so should pop open another instance of ASIO Link Pro window. Note the ASIO Link PRO windows can be closed (they will minimise to the taskbar) provided you keep the application that has called them open.

6. You can repeat step 5 with as many applications as you like: each will open its own ASIO LINK PRO window and feed its audio output directly to the output of the ASIO driver by default.

7. In your Scope project, the audio from your apps will be summed and will come from the ASIO SOURCE module. Connect that to a mixer or hardware output in the Scope project as required.

8. You can set Windows audio to use the ASIOVADPRO devices and again that will be passed to the ASIO driver output. Doing so means you don't have to get windows talking to the Scope wave devices for windows audio.

What is effectively happening is that ASIO LINK PRO is acting as a "wrapper" for the Scope driver, and in doing so it helps it to play nicely with windows apps which would otherwise crash/BSOD if you pointed them directly at the ASIO SCOPE driver.

Note in the above I start an instance of ASIO LINK PRO from the tool, and then have all the apps access it as multiclient. Some apps do not need that intermediary step and could be set to use the first instance of ASIO LINK PRO. But many crash/BSOD when you try to do that. In my experience if you start an instance of ASIO LINK Pro from the Tool first, and then have all the applications access Asio Link Pro in multiclient mode, I can't crash the system.

Read the ASIO Link technology PDF included with the install to learn more about how it works.

A final thought

I hope this (LENGTHY!) write up is helpful to anyone still trying to use the Scope PCI hardware with Windows 10. I make no claim that this is the only or even the best way of doing this, but I have not come across a better method.

That my years old Pulsar cards are still going strong is a source of wonder to me, and I am very grateful to those (Holger, Garyb, and I am sure many others) who have made that happen. It is obvious there is a lot for these guys to do and limited resources to do it. But I wonder if it might be possible to take the ASIO Link technology code and somehow integrate it into the Scope software, so the BSOD problem disappears. Or maybe someone with more extensive knowledge than I could take a look at this, and see if this workaround could be improved/streamlined.

Happy hunting SCOPE users.....

[malcolmbarr]

To give an update: I have been using the workaround described above pretty extensively over the last week, and have to say that now this is set up it is the most trouble free experience with Scope I have had on Windows at any time since purchasing the hardware ages ago.

I have set the PC in question up so Scope 7 opens at start up, and then I use start-up delayer (google it to download the app) to start the ASIO LINK PRO TOOL 32 15 seconds after boot, and run the tool start minimised and start ASIO options selected. I then set all my apps to use the ASIO LINK PRO driver as described above. I have not had a single BSOD crash since setting this up. I have tested with the following software (among others):

Hosts:
Cubase LE 10.5
FL Studio 20
Live Professor 2

Standalone audio apps:
Volatge modular
Arturia V collection
NI Komplete 12
UVI Falcon
Sugar Bytes all apps collection
FXpansion DCAM, Tremor and Geist 2
IL Harmor and Gross Beat
Adobe Audition
PluginGuru Unify

If my experience with this is anything to go by, I would appeal to the devs at Sonic Core to take a look at this (or similar) and consider whether "wrapping" the Scope driver in this way could be built into the way Scope works on Windows.

[garyb]

the DAWs will already work, although Live requires running in win8 compatibility.

that app is not a wrapper. it is an ASIO distributor.

you might as well ask the developers to stop insisting that their apps run the audio device. not all audio devices are Windows soundcards.

[malcolmbarr]

Hi garyb - I know you would not be able to resist a comment!

You stated “ you might as well ask the developers to stop insisting that their apps run the audio device”. The sad truth is that, in many cases, we know that is not going to happen. This problem is simply not pervasive enough for the developers to care. In a perfect world they would, but as we have both learnt through experience, they don’t. And the Scope user base is just too small to make them care.

But there is an asymmetry here. As much as you may have to do so through gritted teeth, what I have documented above (or a similar variant of it) could be implemented under the hood of the Scope driver so that we users would not encounter the BSOD problems. It would mean that the Scope driver had to compromise for this purpose. But it is something you guys could decide to do.

Or you could take the attitude of the developers of the apps, and just say it isn’t your fault.

[dante]

It could be made an option within Scope settings - where the sample rates and latency etc are setup - to use an (ASIO wrapper or - call it - WDM emulation mode) or not. This would be OFFby default, so not changing the default identity of Scope for the majority of users.

[malcolmbarr]

Is the Scope 7 Asio driver multiclient? You could call it multiclient mode if it isn't, as that is another benefit of the workaround above. Or "wider Asio compatability" mode....

[garyb]

who will pay for it?

this solution is fine for you, but it is not so great for others. i get that you don't care about realtime audio, but i do. adding a layer of code just slows everything down. since i don't need stand-alone synths, and if i do, i can use something like bidule, if i don't want a sequencer. really, though, i am very glad that you have a solution that works for you.

[malcolmbarr]

"who will pay for it"

Users do not pay for any one specific feature of the Scope 7 package in isolation. So what I have suggested would be done as part of the general development of the platform, funded as that is via users upgrade fees and the like.

I wonder how many users Scope/sonic-core has lost because of a perception that the platform was not stable enough for use in windows. For all of Scope's many strengths I know I have left and come back to it because of this issue. Many have not come back.

I find it surprising that Sonic-Core or yourself would consider a condition which generates not just an error message, but a complete collapse of the operating system , tolerable in the course of its day to day use. Should that not be a priority to patch out in the course of an upgrade?

"i get that you dont care about realtime audio, but I do"

I do not notice any increased latency or dimunition in performance with what I have described above. I do notice the absence of the BSOD, which generates a lot of latency!!! You might notice that one of the hosts I have tested is designed explicitly for live use of VSTs. The statement that I don't care about real time audio performance has no justification based on this thread.

"i don't need stand-alone synths, and if i do, i can use something like bidule, if i don't want a sequencer"

There are various work arounds for the BSOD, but Bidule is something you have to pay for. ASIO LINK PRO is freeware.

[yayajohn]

Pretty sure we all understand what your asking for and why but you're beating a dead horse (who had that nifty gif of that)
Same argument for XTC/VSTIM mode?

Of course we "want it all" We want Scope to fulfill all of our specific needs and styles.
Reality of a company this size says if you can make it work to fit your needs then do it.
Otherwise move on.

Personally I am very happy with my Xite-1 the way it works right at this moment. Improvements are welcome of course

[malcolmbarr]

Hi Yayajohn

I agree I am likely beating a dead horse. However, I have at least taken the time to document a workaround for the help of others, so I feel entitled to a bit of dead horse beating!

A key difference between this and XTC/VST mode: Sonic Core has at least recognised that delivering XTC should be on the to do list. Not so for BSOD errors, it appears.

A question : does the ASIO xCite driver BSOD in the same way with some windows apps? Or is it just the PCI cards?

[garyb]

there is no way that an ASIO distributor does not add latency. it is probably negligible for your use.

this is not just a wrapper. it is an app that uses the Scope ASIO driver and then makes it's own virtual driver available, adding this to Scope will potentially break it. in the best case scenario, SC would have to develop their own ASIO distribution app in addition to the regular driver. that is why i ask who will pay. there is already plenty of work to do with the other features that SC is slammed about. since there is already a product to bypass this issue, it makes little sense to reinvent the wheel, but that is just my opinion, it's not a policy statement.

also, let's be clear, it is NOT the SC driver causing the blue screen. it is the crappy ASIO app that insists on a response that the Scope hardware will not be capable of making, because it is not a Windows soundcard that is controlled by Windows. the work-around is to NOT connect the app to Scope, but to use a middleman to connect to Scope, and then the app.

again, the Scope DRIVER does NOT bluescreen. the app bluescreens and then blames the driver. i realize that functionally, most users don't care how it happens, just that it does. there are a number of apps that can distribute ASIO including DAWs like Reaper.

[garyb]

A question : does the ASIO XITE driver BSOD in the same way with some windows apps? Or is it just the PCI cards?

if the app attempts to control the soundcard, then yes, a system using the XITE will crash.

it's like the old doctor joke, "doctor, it hurts when i do this". "well, stop doing that.".

for those apps that behave in this way(doing the work, so the children don't have to think), an app that distributes ASIO is a good solution, as you have found.

[yayajohn]

malcolmbarr: my apologies. Thank you for sharing your work-around for others to benefit.
That is exactly what makes Planet Z a great forum.

[garyb]

yes, please don't take my comments as pure negativity. i think this app seems very cool. it solves a lot of problems.

[malcolmbarr]

garyb and yayajohn - nothing but love for you guys, we are all just trying to figure stuff out.

[DragonSF]

A question : does the ASIO XITE driver BSOD in the same way with some windows apps? Or is it just the PCI cards?

if the app attempts to control the soundcard, then yes, a system using the XITE will crash.

it's like the old doctor joke, "doctor, it hurts when i do this". "well, stop doing that.".

for those apps that behave in this way(doing the work, so the children don't have to think), an app that distributes ASIO is a good solution, as you have found.

That's absolutely not true. I made an in depth research on this issue and found, that ASIO and sys driver are internally 32 bit only. If you inquire ASIO driver info (like # of channels), the BSOD will appear, if your app is true 64-bit (i.e. upper address != zero). Live and other DAWs are mostly 32-Bit internally, so they work. If it's 64-bit, the sys driver tries to write to an protected address with upper address 0 and Win obviously creates an exception and dies with BSOD.
A simple solution would be to a) provide all address pointers in the ASIO driver a 64-Bit address type and do the same in the sys driver:

Code: Select all

ASIOError Asio_ScopeBrd::getChannels (long *numInputChannels, long *numOutputChannels)
{
	TRACE("Asio_ScopeBrd::getChannels");

	if (!active || !vxd) {
		TRACE("getChannels: not present");
		return ASE_NotPresent;
	}

	DWORD data [ASIO_MAX_CHANNELS+1];
	DWORD freq;
	GetDelayedFreq(&freq);

	// input channels first
	if (vxd->GetChannelInfo (data, TRUE) != OK) {
		TRACE("getChannels: GetChannelInfo error");       
		return ASE_NotPresent;
	}
	....

The critical section is : DWORD data [ASIO_MAX_CHANNELS+1];
Data structures containing such different sized words refer to them as WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) and QWORD (64 bits/8 bytes) respectively.
correct statement: QWORD data [ASIO_MAX_CHANNELS+1];
But then of course the function vxd->GetChannelInfo has also to be changed to accept QWORD variable sizes.

Code: Select all

int scope::GetChannelInfo (DWORD *data, int isInput)
{
	TRACE ("scope::GetChannelInfo");

	DWORDLONG i_data[3];
	DWORD o_data[1];
	DWORD o_ndata;
	int isz = sizeof(i_data);
	int osz = sizeof(o_data);
	
	i_data [0] = (DWORDLONG) m_iID;
	i_data [1] = (DWORDLONG) isInput;
	i_data [2] = (DWORDLONG) data;


	if (!SendIOControl (IOCTL_SCOPE_CHANNELINFO,
		(LPVOID *) i_data, o_data, sizeof (i_data), sizeof (o_data),
		&o_ndata))
		RETURN_ERROR (IOCTL_FAILED);
...

Critical point is: DWORD o_data[1];

[garyb]

well, that's great and you are really sharp.
now tell Holger, because only users are here.
if you really are trying to be helpful, then help us all by communicating with the person who can help everyone else.

if my understanding is incorrect or incomplete, then thank you for the correction, but i'm not coding. i am reliant on what i have been told.

[DragonSF]

Holger was completely informed about that on Feb 5th 2018 in a messenger chat. I even volunteered to make the changes!
I just want to make clear, that the apps don't do any illegitimate calls - like trying to open a control box. GetChannelInfo is one of the first calls required by ASIO protocol, before opening the driver. That some DAWs just survive is due to the fact, that they operate in the lower address space, which is save.
And I don't blame you, just trying to clarify the situation - which hasn't change, since I detected the issue and a method to fix it.I'm aware of difficulties in the sys driver domain, but the fix and the testing shouldn't take 2 years and more.
If someone gave you the wrong information (intentionally or not), then you know now better.

[garyb]

well, truthfully, i still know the same.
the problem i mentioned did exist in a couple of apps whose owners even wrote patches for it(steinberg and propeller heads). i never thought that they were trying to open a control box, because that was never an issue. where i am an ignorant fool is assuming that the problem with other apps was the same as all apps that had issues.

actually, thanks to your explanation i know something else now. this is a totally different issue and it may have been addressed(maybe even with your help). i also know that some progress has been made on several fronts. i do not know why it has not been seen yet, but an update really is imminent. whether it's a ridiculous amount of time or not is really not something in either of our realms of knowledge. i get that the specific fix is relatively simple, though. i will check with Holger because maybe he got caught up in other messes and simply forgot(doubtful, but he doesn't answer to me, so i don't know). making a living comes first.

[valis]

DragonSF, Messenger (Facebook I presume) is good for connecting and saying hi, but you never know what state people are in when they're on there (maybe he was in a hot tub in the mountains?) I would also think that messenger chats are not very reliable means of getting support, providing a a chain of custody for the info and so on, and I know for a fact that it's a true PITA to find things in later. So I'm not sure if you're implying that Holger is remiss in not responding, but that is how your statement seems in the context you provided. I'll let you deal with Holger as you wish.

As for the forums, they're here for us to help each other but Holger is unlikely to read anything here. And GaryB's time on these forums is like the rest of us, when the other parts of his day are done. So you might forgive the varying degrees of attention that are on display with responses here. A support inquiry via email--one might imagine--is taken care of as part of a daily working routine and therefore at least will get a typical support response and focus. And I would imagine using that approach also puts the information into the correct wheelhouse for Sonic|Core's QA & Feedback mechanisms.

As for the rest of us, we can't really vet the context of that code or make use of it in any way but thanks for sharing.