Presonus deliberately limiting the functionality of the Quantum HD8. This thing is total garbage.

[NoTimeForThoughts]

Well, I'm ultra dissatisfied with this interface, had it less than 24 hours. It will not be bringing its ADAT in as WDM capable inputs. BY DESIGN.

I had a discussion with AI (GPT LUNA 5.6) which went something like:
I said:
getting adat to show up in windows audio inputs for the quantum HD8
AI said:
The Quantum HD8 can appear in Windows Audio Inputs when connected via USB and recognized by the Quantum driver; ensure the HD8 is powered on, connected via USB, and the Presonus Universal Control or Quantum software is installed and running (yada yada a bunch of ways to get it to work that AI has heard work for getting Audio ins, like trying a different USB port)

I say: i'm pretty sure that the Quantum HD8's ADAT in ports are not visible in Windows by design. I have no indication that Windows ASIO can ever or will ever get to see these?

To which AI replies:
You’re right to question that. My previous answer was too broad.
The Quantum HD8’s ADAT inputs are not necessarily exposed to Windows as separate WDM “Audio Inputs.” They are digital hardware inputs, and Windows’ ordinary Sound control panel may show only the analog channels or a stereo device endpoint. (yada yada bunch of excuses)
So I say:
Why would the company that makes this device deliberately deny its users this useful function?

To which AI replied:
Because the HD8 appears to be designed as an 8-channel analog USB interface with ADAT expansion for internal digital routing or monitoring, rather than as a fully expandable USB multichannel interface.

That is a frustrating design choice, but there are several plausible reasons:

• Product segmentation: Exposing ADAT as additional USB/ASIO channels would make the HD8 function more like a higher-end 16-channel interface, potentially competing with PreSonus’s larger Quantum models.

(GPT Luna 5.6)

So I came to the conclusion that the device is complete garbage. By design. Like a taco with bacteria from Mexico on the lettuce.

And I know what you're gonna say man, you can use the Loopback to bring (TWO STEREO ONLY) ins to your OBS from the ADAT ins you want (ONLY 2 of 8 Stereo INS) but that deliberate limitation is a total punk move by some absolute scumbags.

 

[NoTimeForThoughts]

The really ridiculous thing is now I have to get an additional fiber optic cable and run it from the unused ADAT outs of the Quantum 8HD to the unused ADAT Ins of the original interface that only sends outs (or temporarily to the 2nd ADAT ins of the Quantum 8HD until I get something else that sends ADAT outs to there).
So the path is USB to ADAT out (Voicemeeter) then ADAT out (thru the Quantum HD8) to the original interface that it came out of. Now it can come in thru KS or WDM.
Then I can bring it into the OBS. So yeah, How is hobbling a device deliberately with software not associable with garbage? It's the anger it causes. The redundant routing it necessitates.
I looked into reverse engineering the driver but AI says it's not likely.

Of course AI will come up with a different explanation to back the idea that everything is allright and there aren't corrupt and twisted entities beyond the hobbling of modern devices...but that's why we have eyes to see and bodies to protect, so we don't have to think only Fabian thoughts like AI when we got mouths to feed and ears to hear.

 

[SwitchBack]

Did you contact Fender Customer Support, within those 24 hours you had the interface? Pretty sad to come up with this assessment based on some computer generated *stuff* for an interface you had only for a day. WDM is slow and does not support high-I/O interfaces, so all high channel count interfaces use their own proprietary drivers, for audio applications that do support high channel counts. Windows Audio does not.

Oh, and ASIO is just an extra shell to port ASIO compatible hardware to whatever audio application you want to use for the hardware. If that audio application runs inside WDM then those limitations still apply. Windows Audio is *#%*! (non-AI generated answer).

 

[TimC340]

Your inputs from the external device connected to the HD8 via Toslink (ADAT) should be visible in Universal Control. Your inputs in UC should show as 1-8: onboard analogue inputs; 9-10 S/PDIF inputs; 11-18 ADAT inputs. Make sure the external device is locked to the same clock as the HD (44.1/48Khz). In Studio One, open a new Song then go to Song Setup in the Song menu, click on Audio I/O Setup. The matrix there should show your external inputs as ADAT 1-8. If Studio One hasn't generated tracks for these inputs, you can add them from the 'Add (Mono)' button at the bottom. You can then rename them to whatever is appropriate. Click in the matrix to link hardware input ADAT 1 to the created track 1 - an M should appear in that box; the input is now locked. Once you have it set up as you want, save it ('Make Default'). You can now select whichever input you want for each track in the main Studio One window. If this doesn't work, talk to Support - but it should!

Edit: I don't use OBS, so I can't speak to that, but the setup in Universal Control is crucial.

 

[NoTimeForThoughts]

Read thru what I said again. Maybe you will get it. Of course there is a prerequisite that you have to know what WDM is and how interfaces work and KS. I found the KS was the only decent way to bring in my Rolands via USB to VBAN. I have done all this shit and I ain't no studio hand for hire. NSFW all the way here.

But as usual I am met with the same old stuff on a forum. People who don't really go that deeply. I set up my stuff a particular way and there are certain expectations. And that statement "Windows audio is garbage" is un well thought out trash. Oi. Never liked that shit.

 

[NoTimeForThoughts]

Time will tell if the interface is satisfactory, but at the very least it freed up the very satisfactory 1810c for moving to my bedroom setup. I bought a toslink cable for its ADAT outs and that runs to the 1824c's ADAT ins. I don't doubt that the adat ins on the 1824 will serve just fine so I never have to use any sort of creeping loopbacks that I don't understand outside of VBAN.

I put together my bedroom studio finally with the help of all these new computers and moving disk drives out of old computers and into new ones. Pretty much flawlessly. I'll try and posta bout it someplace on here if there is any place to put it. I made a video of the initial event. Just about 2 hours ago and uploaded it to Odysee with a pretty full description.

I still hold with my initial statement that the interface is garbage. It's got that deliberate punk move of taking the WDM and KS ins, going out of their way to program the device not to allow windows to see them. I have a whole long discussion about it with AI. Though I am sure that idiots out there will hate AI and have lots of negative things to say, because without any decent questions you will never be able to see the usefulness of a good thing like AI.
My video of my initial Guitar thing in the bedroom with the old 3900 Ryzen 12 core (bought used in 2023) with the new used Aorus 2080 GPU: https://odysee.com/@SynthesizersNMu...p-For-Live-Recording-Your-Guitar-Noodling(1:7

 

[BobF]

I didn't go thru this thread in detail, so apologies if this is totally unrelated.

Maybe this setting will help ... I keep it off

 

[sintil8]

I have no indication that Windows ASIO can ever or will ever get to see these?

This,
I don't believe Windows uses or has an ASIO driver available ?

Microsoft are currently developing an ASIO driver for windows, which should fix the windows system level multiple in/out issue...

Kindest regards

 

[NoTimeForThoughts]

That's a good idea. I'll try that. Don't have much hope that it will help as there is already no problem getting ADAT to the KS and WDM out of the 1810c and 1824c and never has been, which you can see in VBAN (if you install it) in and out choices if you don't want to install OBS. But you probably don't do anything like that anyways and if you do it will mess with your listings for the others and you will have to reassign them for each of your 11 oscilloscopes you open for your live videos.

I actually went thru a very long conversation with AI about how to get these lists to act right, because the Tor Vergata oscilloscopes have only a short window for viewing the WDM list, so if you have 16 ADAT ins and 16 or 20 Analog ins it can take quite an effort to find the one you want in each of 11 oscilloscopes. AI says that's on the individual program like OBS to sort them or make some way to sort them. I think it also is on Windows to make them list properly it's another thing they never get around to doing. I can't be the only one who had enough interface ins to have noticed it. Live Professor used to have a real good ASIO support listing in it where you could see things from each device and it was sorted.

Just made a short-ish video (5:40) going thru the new Fender version and the new *to me version of the UC. https://odysee.com/@SynthesizersNMusic:5/Understanding-The-Presonus-Quantum-Hd8:d

Worth noticing that in the video I uploaded before, you can easily spot the instances of the ADAT from the 1810c on my new bedroom setup. In this 2nd video here today I uploaded something I made when I understood how the UC works for the Quantum HD8 which if you compare to the brief settings I did in the 1st video (the bedroom video) you can see it's real different.

 

[TimC340]

Read thru what I said again. Maybe you will get it. Of course there is a prerequisite that you have to know what WDM is and how interfaces work and KS. I found the KS was the only decent way to bring in my Rolands via USB to VBAN. I have done all this shit and I ain't no studio hand for hire. NSFW all the way here.

But as usual I am met with the same old stuff on a forum. People who don't really go that deeply. I set up my stuff a particular way and there are certain expectations. And that statement "Windows audio is garbage" is un well thought out trash. Oi. Never liked that shit.

Yes, my bad. I didn’t clock the WDM/KS relevance to OBS. You’re right that WDM doesn’t expose the Quantum HD8 ADAT inputs to OBS. There is an OBS plugin that bypasses WDM and allows it to understand ASIO which should allow discrete control of all the channels from within OBS - https://github.com/Andersama/obs-asio. As I said, I don’t use OBS so I can’t pass on any experience with this.

 

[NoTimeForThoughts]

I made a brief conversation the day before I came on here, actually had two of these conversations, the one I quoted above and this one (the color red has been added to indicate some internal thinking of AI that wasn't visible when I was actually using it):

This conversation was generated using OpenAI's GPT-5.6 Luna Model.

====================
User prompt 1 of 3:
no wdm ins from adat on quantum hd8

Assist:

**The Quantum HD8 does not support WDM inputs from ADAT**, which means you cannot use ADAT inputs as WDM inputs for your audio setup. This limitation may affect how you expand your audio interface capabilities.

Read More
- https://studiooneforum.com/threads/quantum-hd8-or-other-interface.432/
- https://gearspace.com/threads/presonus-debuts-the-all-new-quantum-audio-interfaces.1428401/page-6

--------------------

User prompt 2 of 3 - 9/9/2026, :
what do i got to do to get around this software limitation? Is there any way to mod it or use a alternative driver?

GPT-5.6 Luna:
<!-- **Searching for audio tech specifics**

I need to understand Quantum HD8, WDM, and ADAT, likely related to PreSonus products. Given that these terms are specialized, my best approach might be to conduct a web search for detailed information. I’ll focus on finding the specifics about these products since there may not be much prior context. Exploring relevant terms will help me gather enough details for a thorough understanding. Let's see what I can find! -->
Probably not with a mod or alternative driver. The restriction is most likely in the Quantum HD8’s **USB driver/channel map and firmware**, not a missing Windows setting. A generic ASIO driver cannot normally expose hardware inputs that PreSonus does not present to the operating system, and modifying the firmware or driver could disable the interface or void its warranty.

The practical workarounds are:

1. **Use the HD8 through ASIO in your DAW.**
In Studio One or another ASIO-compatible DAW, select the Quantum HD8 ASIO driver and check whether the ADAT channels are available there—even if they are absent from Windows WDM applications. Create input buses manually for the ADAT channels if necessary.

2. **Use an ASIO-to-WDM bridge.**
If your goal is to use the ADAT inputs in applications that only support WDM/WASAPI—such as games, Zoom, media software, or Windows audio—try an ASIO bridge such as **FlexASIO**, **VB-CABLE**, **Voicemeeter**, or **ASIO Link Pro**. The routing would be:

`Quantum HD8 ASIO → bridge/mixer → virtual WDM input`

This may expose the ADAT channels to other Windows programs, but it does not make the HD8’s native WDM driver support ADAT. It can also introduce latency, clocking issues, or sample-rate conflicts.

3. **Use a separate ADAT-capable interface for Windows WDM.**
Connect the ADAT source to another interface whose Windows driver exposes ADAT channels as WDM inputs, then use that interface as the Windows recording device. This is usually more reliable than a software bridge.

4. **Run the HD8 as an ADAT expander.**
The HD8 reportedly has an ADAT standalone mode, allowing its analog inputs/outputs to function through another ADAT-equipped interface. In that arrangement, the other interface—not the HD8—handles the USB/WDM connection to the computer. [1]

5. **Use an external digital mixer/router.**
A device such as an RME interface with TotalMix, a suitable digital mixer, or another hardware ADAT router can combine and route the channels before they reach Windows. This is the most dependable option if you need the ADAT channels in multiple applications simultaneously.

Before buying anything, test the bridge with a short configuration:

- Set both devices to the same sample rate, preferably 48 kHz.
- Use the Quantum’s native ASIO driver in the bridge.
- Select the virtual WDM input in the target application.
- Verify whether the ADAT channels appear individually.
- Disable exclusive-mode control in Windows if applications keep changing the sample rate.
- Expect additional latency and avoid running multiple ASIO applications at once.

I would **not** attempt a firmware hack or replace the PreSonus driver with a generic ASIO driver. The realistic solutions are an ASIO-to-WDM bridge, a second interface, or using another ADAT-equipped interface as the computer-facing device.

Read More
[1] Quantum HD8 or other interface? — https://studiooneforum.com/threads/quantum-hd8-or-other-interface.432/

--------------------

User prompt 3 of 3 - 9/9/2026:
How would I go about modding the driver? Can I separate the driver out of the universal control?

GPT-5.6 Luna:
<!-- **Searching for mod driver explanation**

I see the user needs a specific answer about how to mod a driver. I realize I should proceed with caution and explain the process of package extraction on Windows. This likely involves some technical details, so searching the web for the most current and relevant information seems necessary. I want to make sure I provide the user with clear and accurate guidance! Let's get started on finding that info. -->
You can separate the Windows driver files from the Universal Control installer, but that does **not** make the driver open-source or easily modifiable. Universal Control is mainly the installer, control-panel software, firmware updater, and bundled PreSonus driver; the driver itself is a signed Windows kernel/user-mode package.

The important distinction is:

- **Extracting the driver:** possible.
- **Installing it independently:** sometimes possible.
- **Changing its channel map:** technically possible only with substantial reverse engineering.
- **Installing a modified version:** blocked by Windows driver-signature enforcement and potentially by the device’s USB/firmware protocol.

On Windows, you can inspect the installed package without modifying anything:

1. Disconnect the HD8.
2. Open **Device Manager** and enable **View → Show hidden devices**.
3. Find the Quantum HD8 under **Sound, video and game controllers**.
4. Open **Properties → Driver → Driver Details**.
5. Note the `.sys`, `.dll`, and `.inf` locations.
6. You can also inspect the driver store from an elevated Terminal:

```text
pnputil /enum-drivers
```

The package will usually be under a path resembling:

```text
C:\Windows\System32\DriverStore\FileRepository\
```

Universal Control’s downloaded installer can often be opened with 7-Zip or extracted from the system’s temporary installation directory. Look for `.inf`, `.sys`, `.dll`, and catalog `.cat` files. Do not replace the originals; copy them to a separate work directory.

A modified driver would require determining where the driver defines:

- the USB audio interface descriptors it expects;
- the number and order of input/output streams;
- the WDM pin factory definitions;
- the channel names and data formats;
- the ASIO-to-WDM routing;
- sample-rate and clock handling.

If the ADAT channels are absent from the HD8’s USB descriptors or firmware stream layout, changing a Windows channel table will not help—the computer never receives those channels. If they are present in ASIO but omitted from WDM, the likely target would be the driver’s WDM pin/channel exposure, not Universal Control itself.

The usual reverse-engineering workflow would be:

1. Capture the HD8’s USB descriptors with USB Device Tree Viewer or USBPcap.
2. Compare the channels exposed in ASIO with those exposed in Windows Sound settings.
3. Inspect the `.inf` and driver binaries using tools such as Ghidra or IDA.
4. Identify the WDM/KS pin and channel-format structures.
5. Patch the user-mode component if the mapping is there.
6. Re-sign the modified binaries and install them in a test environment with signature enforcement disabled.
7. Test only on a separate Windows installation or restore point.

You should **not** disable driver-signature enforcement on your normal system or use a driver-signing bypass for everyday operation. A kernel-driver mistake can cause crashes, audio corruption, or boot problems, and a Universal Control update will likely overwrite the modification. It may also void support or warranty coverage.

A safer experiment is to leave the PreSonus driver untouched and intercept its ASIO output with a bridge. If the ADAT channels are visible in ASIO, a bridge can expose them as virtual WDM inputs. If they are not visible in ASIO either, driver modification is unlikely to solve it because the limitation is probably in the hardware/firmware stream design.

The first useful test is therefore: open a DAW, select the Quantum HD8 ASIO driver, and check whether ADAT channels appear as input ports. That result tells you whether you are dealing with a WDM-only omission or a deeper hardware/firmware limitation. PreSonus distributes the Quantum driver through Universal Control and also provides current and legacy packages through its product downloads, so testing an older official package is safer than patching one. [1,2]

Read More
[1] Quantum HD 8 USB-C Audio Interface — https://www.presonus.com/products/quantum-hd-8-usb-c-audio-interface
[2] Where can I find the latest drivers for my PreSonus device? — https://support.presonus.com/hc/en-...ind-the-latest-drivers-for-my-PreSonus-device

 

[NoTimeForThoughts]

Well I went over the 10000 character limit there (good old AI never shuts up) so to continue:
Anyways as I said above I got a simple but seemingly good quality 1.5m TOSLINK cable the next day for only about 4 dollars at the home improvement store. Since it was easy enough to connect the Quantum HD8's unused ADAT outs to the 1824c's unused ADAT ins, I will be able to get the needed ins from the USB interface JP 08 and System 1m (the System 1m sounds terrible used via its analog outputs when running with modular cables real real bad and both synths' USB driven audios sound terrible thru WDM and must be run in as KS to VBAN or they would be unusable) from the path of USB->Vban>ADAT 1824cout->ADAT HD8in->ADAT 1824cin->OBS->video.

 

[NoTimeForThoughts]

Yes, my bad. I didn’t clock the WDM/KS relevance to OBS. You’re right that WDM doesn’t expose the Quantum HD8 ADAT inputs to OBS. There is an OBS plugin that bypasses WDM and allows it to understand ASIO which should allow discrete control of all the channels from within OBS - https://github.com/Andersama/obs-asio. As I said, I don’t use OBS so I can’t pass on any experience with this.

Yeah strike any mention of ASIO that I ever made. I never use ASIO at all. Maybe somethings I used in the past such as ASIO4all had it, but I only use the OBS dialog which only shows Windows Audio Ins when I make an in. So I know, from past experience that ASIO sucks real bad and caused lots of problems with BSODs in my old setups which were always laptops (stubborn coffee house brain made me love laptops for some reason) up till I got "Desktop" computer for the first time using a RTX GPU for the first time in 2023.

Seems like the ASIO was something I used to try and use in Pro Tools back around 2012-2017. I recall it as causing static to seem to shut on all of a sudden in there and it could be reverted by changing the buffer size. Especially happened on battery power. But also happened off battery and a lot of BSODs were common all through those years. You can see a lot of interrupted live streams I did between 2017 and 2022 that were caused by that.

Not that I always used ASIO4all. Which I quit using long before those days. The Static was common the bsods were common and then someone working with OBS came out with that driver which was going to allow us to use only mono ins. The only times I used that I got the BSODs. So I quit using it. Every single use of ASIO in Windows resulted in negative things. So MY bad, I should not have mentioned ASIO. Asking AI i discover that OBS is just using Windows given audio device list.

Now if you were to say to me "ASIO is shit" well then you would probably get no argument from me just based on my experiences. So yeah I was wrong, it's not an ASIO list that I used in OBS. It's just the OBS dialog for properties of an audio in source and that according to AI is:

In OBS, when you add Audio Input Capture and open Properties, the device list is generally showing Windows audio recording devices, not ASIO devices.

That means OBS is usually accessing them through Windows Audio/WASAPI—the standard Windows audio system. The entries may include:

• Your built-in microphone
• A USB microphone
• Inputs on a USB audio interface
• A capture card’s audio input
• Virtual devices such as Voicemeeter or VB-CABLE

OBS does not normally use ASIO for that source. If you want to select an ASIO device or individual ASIO channels, you generally need a separate third-party ASIO Input Capture plugin. OBS’s regular audio input source and ASIO capture are separate paths. obsproject.com

The practical distinction is:

• Audio Input Capture → Device: Windows audio/WASAPI-style device, usually simple and compatible.
• ASIO Input Capture: ASIO driver and channel-level access, often useful for DAWs and multichannel interfaces.
• Audio Output Capture: Captures a Windows playback device, such as speakers or headphones.
• Desktop Audio: Captures system playback according to OBS’s configured Windows audio device.

So if your interface appears as something like “Microphone (USB Audio Device)” or “Line In (Focusrite…)” in the regular Properties list, OBS is using its Windows-facing audio device—not necessarily the interface’s ASIO driver. Windows audio APIs expose devices such as WASAPI separately from ASIO, which is why programs may show different device lists. scsynth.org

But with the foresight of my next query to AI (in the next post here) it would be wrong to call ASIO shit, and everything falls on the beleagured M Audio Fast Track Ultra and Fast Track Ultra 8R interfaces I was so fond of during those years:

 

[NoTimeForThoughts]

As long as I was on the subject of ASIO I asked AI about my old problems with BSODS and this was the reply:

Why was I getting so many BSODs when I used Live Professor and Pro Tools and OBS at the same time, or Live professor, Studio One and OBS, along with desktop synths and the Fast Track Ultra 8R?

The most likely culprit was the Fast Track Ultra 8R’s old Windows driver, especially its ASIO implementation—not the fact that LiveProfessor, Pro Tools/Studio One, and OBS were simply open at the same time.

You had several demanding audio paths competing for one aging USB interface:

• Pro Tools or Studio One: opening the interface through ASIO
• LiveProfessor: also needing ASIO input/output
• OBS: trying to capture audio through Windows audio/WASAPI or another driver path
• Desktop synths: using Windows audio, ASIO, or virtual MIDI/audio routing
• Fast Track Ultra 8R: relying on a legacy USB/ASIO driver

That can expose driver bugs involving:

• Multiple programs opening the ASIO driver at once
• Switching sample rates or buffer sizes
• ASIO and Windows audio accessing the interface simultaneously
• USB power-management or USB-controller problems
• Driver timing failures under heavy real-time load
• Poor handling of suspend/resume, device reconnects, or sample-rate changes

A defective user-mode audio application normally crashes only itself. A BSOD usually points to a kernel-mode driver, making the Fast Track driver, USB driver, or another low-level audio/virtual-cable driver the prime suspects. Historical reports specifically describe the Fast Track Ultra/8R ASIO driver causing BSODs, dropouts, crackling, and failures when used with DAWs. homerecording.com The device is also not listed among the hardware currently supported for Windows 11, and M-Audio notes that products absent from its compatibility list are not considered supported. m-audio.com

The likely sequence was something like:

1. LiveProfessor claimed the Fast Track’s ASIO driver.
2. The DAW tried to open the same driver or force a different format.
3. OBS accessed the Windows-facing side of the same device.
4. A driver bug or timing conflict occurred.
5. The driver made an invalid kernel-level operation and Windows halted with a BSOD.

It does not necessarily mean the CPU was too slow. The more important issue was probably driver stability and device ownership.

For a stable setup, use one audio “owner”:

• Let LiveProfessor own the Fast Track through ASIO.
• Route LiveProfessor’s processed output to OBS through a separate virtual audio device or loopback path.
• Avoid having the DAW and LiveProfessor both use the Fast Track ASIO driver simultaneously.
• Keep OBS from using the Fast Track directly if LiveProfessor is already using it.
• Use one sample rate everywhere—usually 48 kHz for OBS/video—and one buffer size.
• Disable USB selective suspend and avoid USB hubs.
• Use a direct USB port, preferably a USB 2.0 port if available.
• Check the BSOD dump with a tool such as BlueScreenView or WinDbg. If it names an M-Audio, ASIO, USB, virtual-cable, or audio filter driver, that would strongly confirm the cause.

One important correction to the earlier explanation: ASIO drivers can sometimes support multiple applications, but that is driver-dependent. “Multi-client ASIO” is not guaranteed. The Fast Track Ultra 8R’s age and unsupported status make it especially risky in a setup combining several audio hosts.

 

[NoTimeForThoughts]

But hey you wait, I wasn't done. I then asked AI the following about my old setup:

Could it not have been the computer? I used laptops at the time. They were running off the power outlets not the batteries, but they were not very powerful like desktop computers with dedicated GPUs RTX with VRAM. I used a Lenovo Y70 back in 2017-2018, an ASUS GLC7...something was the first computer to ever have a Ryzen 7 with 8 cores

Yes, it could have been the computer—but “not powerful enough” usually causes dropouts, crackles, freezes, or application crashes, not BSODs. A BSOD generally means a kernel-level driver encountered a fatal error. The computer may have triggered the problem through its USB, chipset, power-management, or graphics/network drivers, while the audio driver was the component that failed.

The GPU and its VRAM were mostly irrelevant to this workload. LiveProfessor, Pro Tools/Studio One, OBS, and desktop synthesizers primarily stress:

• CPU scheduling and real-time audio threads
• RAM
• USB-controller stability
• DPC/interrupt latency
• storage and video-encoding performance
• audio and chipset drivers

A dedicated RTX GPU can help OBS’s video encoding, but it does not directly make ASIO audio more stable. A modest laptop with a good audio driver can work better than a powerful desktop with a faulty one.

Your ASUS was probably the ROG Strix GL702ZC. That model was unusual: it used a desktop Ryzen 7 1700 with 8 cores/16 threads and an RX 580, rather than a conventional low-power laptop CPU. It was marketed as the first consumer laptop with a desktop-grade Ryzen processor.
So it was not weak in CPU terms. The Lenovo Y70 was older, but it also should have been capable of running a DAW, LiveProfessor, and OBS if the system and drivers were configured well.

The computer could still have contributed in several ways:

• The laptop’s USB controller may have had poor interaction with the Fast Track Ultra 8R.
• Wi-Fi, Bluetooth, GPU, or storage drivers may have produced high DPC latency.
• Laptop power-management firmware may have suspended or power-throttled USB devices.
• Heat could have caused CPU throttling, increasing audio dropouts.
• OBS encoding could have consumed enough CPU to leave too little real-time headroom.
• Multiple applications may have requested different sample rates or buffer sizes.
• A USB hub, overloaded USB bus, or marginal cable could have caused resets.
• The older M-Audio driver may simply have been incompatible with that particular laptop’s chipset or Windows installation.

The fact that the laptops were plugged in helps, but it does not eliminate laptop-specific power management. “Plugged in” does not necessarily mean every CPU core, USB port, PCIe link, Wi-Fi adapter, or GPU is operating in a fully unrestricted mode.

A useful distinction is:

• High CPU load: pops, dropouts, sluggishness, buffer underruns.
• High DPC latency: audio glitches and sometimes apparent freezes.
• Bad kernel driver: BSOD.
• Overheating or defective hardware: shutdowns, lockups, or BSODs.
• Power/USB instability: disconnects, audio-device resets, lockups, and sometimes BSODs.

So my best assessment is: the laptops may have been part of the trigger, but lack of RTX-class graphics power was probably not the root cause. The more likely combination was an old Fast Track driver plus simultaneous ASIO/Windows-audio access, with the laptop’s USB, power, or chipset drivers determining whether that combination remained stable.

If you still had the old crash records, the decisive evidence would be the BSOD stop code or minidump. Driver names such as maudio, m-audio, USBXHCI, Wdf01000, ndis, nvlddmkm, or a virtual-audio driver would help distinguish the interface driver from the laptop platform.

 

[NoTimeForThoughts]

continues:

Yeah I still use the Ryzen 7 ASUS GL702ZC all the time. I remember I always saw M Audio in the BSODs.

That strongly points to the M‑Audio Fast Track Ultra 8R driver as the primary cause, rather than the GL702ZC being underpowered. The laptop’s Ryzen 7 had ample CPU capacity for those applications; the driver was likely crashing in Windows’ kernel while handling USB audio, ASIO access, or device power-state changes.

The laptop could still have acted as a trigger—through its USB controller, power management, or chipset drivers—but if the BSOD repeatedly named an M‑Audio component, the practical diagnosis is:

Fast Track driver failure, exposed by a demanding multi-application setup.

The combination was especially stressful:

• LiveProfessor and Pro Tools/Studio One competing for ASIO access
• OBS accessing the device through Windows audio
• Multiple real-time audio streams and plugins
• Possible sample-rate or buffer-size changes
• An old interface driver running on a newer Windows/laptop platform

If you use the system today, the safest arrangement is to let only one application own the Fast Track’s ASIO driver. For example, let LiveProfessor use it, then send LiveProfessor’s output to OBS through a separate virtual audio route. Avoid selecting the Fast Track directly in OBS or another DAW at the same time.

Also keep these fixed:

• One sample rate across all applications, such as 48 kHz
• One stable buffer size, such as 256 or 512 samples
• No USB hub if possible
• USB selective suspend disabled
• The same physical USB port whenever possible
• No automatic sample-rate switching
• Updated chipset and USB drivers, if available

If the old M‑Audio driver is still installed but you no longer use the Fast Track, removing it—or disabling its device and associated driver—would be sensible. If you do still use the interface, avoid replacing a working driver casually; old hardware sometimes becomes less stable with newer unofficial driver packages.

Any difference if I state that I ran the OBS out to a 2nd computer via NDI to encode the video elsewhere?

Yes—it changes the analysis somewhat, but it doesn’t make the M‑Audio driver less suspicious.

Sending OBS to a second computer over NDI means the first laptop was probably doing capture, scene composition, audio mixing, and NDI transmission, while the second computer performed the final stream/recording encode. That reduced the first laptop’s encoding workload, but OBS still had substantial work to do, and NDI added continuous network-video processing and traffic. NDI is intended for sending video and audio over a local network in a dual-computer setup; wired gigabit Ethernet is generally recommended. obs-versions.com

So the first laptop may have been dealing with:

• LiveProfessor’s real-time ASIO processing
• Pro Tools or Studio One’s ASIO processing
• OBS audio capture/mixing
• OBS scene rendering
• NDI video/audio packaging
• USB traffic from the Fast Track Ultra 8R
• Network-driver interrupts and packet processing

That could increase CPU scheduling and DPC pressure, particularly on an older laptop. It could also expose problems in the Ethernet/Wi-Fi driver or NDI plugin. NDI itself might have caused dropped frames, stuttering, or synchronization problems, especially over Wi-Fi or a busy network.
However, NDI would not normally directly cause a BSOD. If the blue screens specifically mentioned M‑Audio, the most likely chain is:

NDI and OBS increased real-time system load → USB/audio timing became more demanding → the old M‑Audio kernel driver failed.
In other words, NDI may have been the stress multiplier, not the underlying faulty component.

The second computer’s GPU also does not fully remove the first computer’s graphics workload. The sending laptop still has to capture and render the OBS scene before sending it over NDI. The second computer handles the final encoding, but the first computer still needs enough CPU/GPU capacity to run OBS smoothly.

One additional possibility: if the two computers communicated over Wi‑Fi, the wireless driver could have contributed to system instability. If they used wired Ethernet, NDI-related network load is a more plausible source of extra scheduling pressure than a fundamental performance limitation.

The most revealing comparison would have been:

• Fast Track + LiveProfessor + DAW, without OBS/NDI
• Fast Track + OBS/NDI, without the DAW
• OBS/NDI using a different audio device

If the crashes followed the Fast Track in all cases, that would strongly implicate the M‑Audio driver. If they occurred only when NDI was active, then NDI/network or its interaction with the audio driver becomes more likely.

Well of course I used Gigabit ethernet I'm not an animal.

 

[NoTimeForThoughts]

continues:

Fair point—Gigabit Ethernet makes network bandwidth an unlikely problem. NDI could still add CPU scheduling and network-driver activity, but it probably wasn’t saturating the link or causing ordinary packet loss.

Given that setup, the likely diagnosis becomes even clearer:

• The GL702ZC had enough CPU power.
• The second computer handled the expensive final video encoding.
• Gigabit Ethernet provided ample NDI bandwidth.
• The recurring M‑Audio name in the BSODs points to the Fast Track driver.
• OBS/NDI and the DAW likely increased real-time scheduling pressure enough to trigger the driver’s failure.

So NDI probably wasn’t the root cause. It may have been an additional workload that made the old M‑Audio driver fail more readily, but the underlying problem was likely the Fast Track Ultra 8R’s kernel/ASIO/USB driver or its interaction with the laptop’s USB and power-management stack.

Any difference if I state that I was definitely using all 8 ins and all 8 outs on the interface and patching back the audio out of Studio One to the ins to take it in OBS?

Yes—that makes the setup substantially more demanding and makes the M‑Audio driver/clocking path an even stronger suspect.

Using all eight inputs and outputs means the Fast Track was continuously handling a full multichannel stream in both directions. Routing Studio One’s outputs physically back into the interface’s inputs for OBS also created an additional real-time round trip:

Studio One → Fast Track outputs → cables/loopback → Fast Track inputs → OBS

That adds:

• More simultaneous USB audio transfers
• More ASIO buffers and channel bookkeeping
• Extra input-to-output latency
• More opportunities for sample-rate or clocking problems
• Potential analog feedback or duplicated-monitoring paths
• Greater stress on the interface’s old driver than using only one stereo input/output pair

The key point is that eight channels alone should not overwhelm a competent interface. At 44.1 or 48 kHz, even 8-in/8-out audio is tiny compared with Gigabit Ethernet. But it can expose weaknesses in an old driver, particularly when several programs are accessing the interface or when one program is using ASIO while another uses Windows audio.

The physical loopback itself usually would not cause a BSOD. It could cause feedback or clipping, but a blue screen still implicates a faulty kernel-level driver. In your case, the likely chain was:

Heavy 8×8 ASIO use + physical output-to-input loopback + multiple audio applications → driver timing/USB-state bug → M‑Audio driver BSOD.

There is also a possibility that you were not actually running a single unified eight-channel stream. If Studio One and LiveProfessor were opening the interface separately, or if OBS was accessing the same hardware independently, the system may have been using multiple competing driver clients. Whether that works depends on the Fast Track driver’s multi-client support.

A more stable design would have been to keep the interface under one ASIO host and route internally:

• Use LiveProfessor or Studio One as the sole owner of the Fast Track ASIO driver.
• Send the processed stereo mix to OBS through a virtual audio cable, ReaStream, or another software route.
• Avoid physically looping outputs back into inputs unless the interface’s mixer/routing requires it.
• If physical loopback is necessary, use one dedicated stereo pair rather than all eight channels.
• Keep every application at the same sample rate and fixed buffer size.
• Disable direct monitoring on the loopback path if it creates doubled or delayed audio.

So yes: the 8×8 usage and physical loopback could very plausibly have increased the frequency of the crashes, but they still sound like triggers for a fragile M‑Audio driver, not evidence that the GL702ZC lacked the performance to do the job.

And what if I state that I was not running 1 but 2 Fast Track Ultras, one an 8R and one just a Fast Track Ultra, into the same machine in order to use one interface on Pro Tools or Studio One or Cubase or Ableton as the 'main DAW' and another on Live Professor as a "synth daw" with some synths running or else possibly just out of desktop synths?

 

[NoTimeForThoughts]

Yes—that detail makes the setup considerably more likely to produce instability.

You were not merely running several audio programs. You were running two separate USB audio interfaces, each with its own M‑Audio driver/device state, while assigning one to the main DAW and the other to LiveProfessor. That creates several potential failure points:

• Two M‑Audio USB devices competing for USB-driver and system scheduling attention
• Two separate ASIO streams running at the same time
• Two independent hardware clocks
• Multiple DAWs and hosts opening audio devices concurrently
• Full multichannel input/output traffic on at least the 8R
• Physical routing between interfaces or through the same interface
• OBS receiving a looped-back signal
• Desktop synths potentially adding more Windows audio or MIDI drivers

The clock issue is particularly important. The Fast Track Ultra and Ultra 8R each have their own digital clock. Even if both are set to 48 kHz, their clocks are not perfectly identical. Over time, one device produces or consumes samples slightly faster than the other. A professional system solves this with word-clock synchronization, an aggregate-device mechanism, or resampling. Two ordinary USB interfaces generally do not have that kind of shared synchronization.

If the two interfaces were kept as separate devices—one entirely for the main DAW and one entirely for LiveProfessor—the clock mismatch might not immediately cause a crash. But once you routed audio between them, combined them in OBS, or monitored one against the other, the system had to handle streams whose timing could drift. Typical symptoms would be:

• Clicks and pops
• Gradual loss of synchronization
• Buffer underruns
• Audio slowly slipping out of alignment
• Sudden device resets

A kernel-driver bug could turn that sort of stress into a BSOD. Since you repeatedly saw M‑Audio named in the crash, the most plausible overall explanation is:

Two old M‑Audio USB/ASIO devices + independent clocks + multiple DAWs/hosts + multichannel routing + OBS created a driver edge case that the laptops exposed under real-time load.

This does not mean the Ryzen laptop lacked power. The total audio bandwidth was modest, and the 8-core Ryzen was more than capable. The difficult part was maintaining stable, synchronized, low-latency operation across multiple old drivers and USB devices.

A more robust architecture would have been:

1. Use one interface as the sole ASIO device for the main DAW.
2. Use the other only for LiveProfessor if it did not need to exchange tightly synchronized audio with the first.
3. Route the final stereo mix to OBS through a software loopback or virtual audio device.
4. Avoid having multiple applications open the same M‑Audio ASIO driver.
5. Keep both interfaces at the same sample rate, but remember that this alone does not synchronize their clocks.
6. Prefer one modern multichannel interface if synchronized I/O between the DAW, synths, and OBS is required.

 

[NoTimeForThoughts]

So the additional interface detail shifts the conclusion from “possibly an old M‑Audio driver under load” to “a very plausible multi-interface, multi-clock, multi-driver failure scenario—still most likely involving the M‑Audio drivers rather than inadequate computer performance.”

Well any audio out of the Live Professor II or desktop synth would have gone out the analog outs to the ins on the other interface. There was no virtual cabling or loopback in the early days at least. Not until I got the Rolands in 2020 and began using VBAN to bring their audio from their USB interface ins back thru ADATs in late 2022 when I got both a Presonus 1810c and 1824c at the same time. and 3 months after that (I can't remember if there were bluescreens) I got the desktop Aorus X570 with the GIGABYTE 2070s and never had another bluescreen or very very rarely at least and possibly for entirely different reasons.

That clarification changes the diagnosis in an important way: the analog routing itself was probably not a clock-synchronization problem.

If LiveProfessor or a desktop synth went through analog outputs into the other interface’s analog inputs, each interface performed its own conversion independently, but you were not digitally combining two unsynchronized sample streams. You would still get:

• Conversion latency
• Possible level, noise, and ground-loop issues
• Analog feedback if monitoring was misrouted
• Two separate USB audio streams for Windows to schedule

But you would not get the same direct digital clock-drift problem as when combining two digital interfaces or synchronizing two separate digital streams.

The more likely failure scenario was therefore:

Two older M‑Audio USB interfaces, both active at low latency, with separate ASIO drivers, multiple DAWs/hosts, full multichannel I/O, OBS, and heavy analog routing—on a laptop USB/power-management stack.

The fact that the BSODs named M‑Audio still strongly implicates the M‑Audio drivers. The laptops may have contributed through their USB controllers, chipset drivers, power management, or DPC scheduling, but the driver was probably the component that ultimately failed badly enough to crash Windows.

Your later history also supports that interpretation:

• The Presonus 1810c and 1824c were newer interfaces with more mature drivers and a more consistent driver ecosystem.
• Using VBAN and later ADAT changed the routing architecture, reducing reliance on the old Fast Track drivers.
• The desktop Aorus X570 system likely had more robust power delivery, USB resources, cooling, and chipset support.
• The RTX 2070 Super may have helped OBS rendering or encoding, but it probably was not the main reason the BSODs stopped.
• Different hardware and drivers mean the old M‑Audio failure condition may simply no longer have existed.

The later Presonus setup was not automatically immune—two interfaces can still create clock and driver-management issues—but if they were linked using ADAT, one device could generally serve as the clock source and the other could synchronize to it. That is much more controlled than treating two old USB interfaces as unrelated ASIO endpoints.

So the revised conclusion is:

Your computers were capable enough, and the analog loopback was not inherently wrong. The recurring M‑Audio BSODs were most likely caused by the old Fast Track drivers interacting with two simultaneously active interfaces, multiple low-latency audio applications, and the laptop’s USB/power-management environment. The newer interfaces and desktop platform removed several of those weak points, explaining why the crashes largely disappeared.

you know I mean desktop synths on the windows desktop right? Not desktop synths like a 3rd Wave or Prophet 10 Rev 4

Yes—I understand. You meant software synthesizers running on Windows, not physical desktop hardware synthesizers such as a Sequential Prophet-10 or Groove Synthesis 3rd Wave.

That distinction matters because the software synths added more load inside the computer:

• They ran as instruments in the DAW or as standalone applications.
• They generated audio through the computer’s CPU.
• They used the selected audio driver—usually ASIO if hosted in a DAW.
• They added plugin processing, MIDI handling, and real-time scheduling.
• Their audio then went out through one interface’s analog outputs and into the other interface’s analog inputs.

So the signal path was likely something like:

Software synth → LiveProfessor or DAW → Fast Track outputs → analog cable → other Fast Track inputs → main DAW/OBS

That still was not a digital clock-combination problem in the strict sense, because the signal crossed through analog conversion. But it did mean that the computer had to maintain multiple real-time audio engines and two USB audio devices simultaneously.

If the synths ran inside LiveProfessor, LiveProfessor owned one interface’s ASIO path. The main DAW owned the other. That arrangement is more plausible than both programs fighting over one ASIO device, but it still depended on two old M‑Audio drivers operating reliably at the same time. The analog re-entry added latency and another pair of conversions, but it probably was not what caused the BSOD by itself.

So yes: I understand “desktop synths” here as software synths on the Windows desktop, and that makes the CPU/real-time-driver workload more relevant than I would infer from the phrase “desktop synths” alone.

 

[TimC340]

As this seems to be a conversation mainly with AI - and to make sure that I’d actually understood your issue correctly and given an answer that did address the problem you appear to have, I recruited Gemini to answer - probably not as comprehensively as the AI you used. However, the big takeaway is that this is standard for multi-channel ADAT-capable interfaces and not a Fender/PreSonus design choice intended to frustrate users!

The user, posting under the name NoTimeForThoughts is frustrated that the PreSonus Quantum HD8 audio interface does not expose its ADAT expansion inputs directly as WDM (Windows Driver Model) audio devices in Windows.

Because Windows WDM does not see these ADAT inputs, non-ASIO software—such as OBS Studio (by default), web browsers, Zoom, or standard media applications—cannot directly select the ADAT channels as standard Windows recording inputs.

Is It a Genuine Issue?

Yes and No:

Technically Valid Limitation: The user is correct that the PreSonus Windows driver does not expose all ADAT expansion channels as standard WDM input devices. Audio manufacturers frequently limit WDM endpoints to primary analog inputs/outputs or stereo loopback streams to prevent driver instability, CPU overhead, and channel clutter within standard Windows audio settings.

Industry Standard Design: This is standard practice for high-channel-count professional audio interfaces. Digital expansion inputs like ADAT are meant to be accessed via multi-channel ASIO drivers inside professional Digital Audio Workstations (DAWs) like Studio One, Pro Tools, or Reaper, where all ADAT channels function properly.

Workarounds Exist: Other forum members point out that this is not a hardware defect or a deliberate attempt to break functionality. Standard solutions for streaming or routing via OBS include:

Using the obs-asio plugin for OBS Studio to read the interface's native ASIO driver directly.

Routing the ADAT inputs inside a DAW or Universal Control software to the interface's built-in stereo loopback channels (WDM compatible).

Utilizing software audio bridges such as FlexASIO, Voicemeeter, or ASIO Link Pro.

I’d stay away from ASIO4ALL. The native Fender HD ASIO is pretty good, as these things go.