Can I use two unique ASIO audio devices at once?

I have a test script in which I am evaluating the spatial audio performance of several MEMS microphones placed around a Head and Torso Simulator (HATS). The MEMS microphones are connected via USB to a miniDSP MCHStreamer Lite (https://www.minidsp.com/products/usb-audio-interface/mchstreamer-lite) and I have an array of speakers at various elevation angles being controlled by an RME Fireface UFX+ and external power amplifier.

My question is, is there a way to simultaneously use a miniDSP ASIO driver for input capture and an RME ASIO driver for output playback? I was using the audioPlayerRecorder function with the RME device connected to the speaker array and a single non-MEMS reference microphone. I briefly attempted to use audioDeviceWriter (RME ASIO driver) and audioDeviceReader (miniDSP ASIO Driver) in the same while loop per the following code but then I received the following error:

Device Writer (Playback only)
deviceWriter = audioDeviceWriter(...
    'Driver','ASIO',...
    'Device','ASIO MADIface USB',...
    'SampleRate',fs,...
    'ChannelMappingSource','Property',...
    'ChannelMapping',33:34);
Device Reader (Capture only)
deviceReader = audioDeviceReader(...
    'Driver','ASIO',...
    'Device','miniDSP ASIO Driver',...
    'SampleRate',fs,...
    'ChannelMappingSource','Property',...
    'ChannelMapping',1:2:15);

while ~isDone(fileReader)
    audioData = fileReader();
    deviceWriter(audioData);
    acquiredAudio = deviceReader();
    fileWriter(acquiredAudio);
end
release(fileReader)
release(deviceWriter)

Error using audioDeviceReader/setup

PortAudio Error: Device unavailable

Error in audioDeviceReader/setupImpl

The MCHStreamer Lite does have a Toslink Optical out cable, so I'm going to see if I can squeeze that into my current hardware setup and just rely on the RME device, but in the meantime I would appreciate any advice.

Answer 1

[Jimmy Lapierre]

Unfortunately, Windows does not allow loading multiple ASIO drivers at the same time, so MATLAB cannot do so. You might be able to get around this limitation using ASIO4ALL if it can be used to specify these devices as input and output. But no guarantee there, and that won't necessarily give you "native" ASIO performance.

[Michael Sonnenberg]

Hmm ok I'll mess around with ASIO4ALL and see if I can get something working. Thanks for the info.

[Michael Sonnenberg]

Hey @Jimmy Lapierre can I ask where you got the info regarding "Windows does not allow loading multiple ASIO drivers at the same time"?

As a test, I was able to use Matlab to control the RME ASIO device to ouput to my power amp / speaker and at the same time I was able to use Adobe Audition to record via the miniDSP ASIO driver.

Assuming this was not a glitch, would I perhaps be able to use parallel processing in Matlab to control the two ASIO devices? I haven't used parallel threads before in Matlab, I just know that is a thing.

[Jimmy Lapierre]

Looks like there are now drivers that support it, I didn't even know! (this link also discusses ASIO4ALL)

https://gigperformer.com/how-to-use-a-single-client-asio-driver-with-multiple-applications-on-windows/

Using multiple threads would not make a difference. In any case MATLAB plays safe and as far as I know, does not attempt to load several ASIO drivers at once.

By the way, does the miniDSP support low latency full duplex WASAPI (I think the RME does)? Because this might be an interesting use case to justify adding support for that. At the moment, Audio Toolbox only does low latency and/or full duplex with ASIO.

[Michael Sonnenberg]

That is a good question. Let me get back to you on WASAPI.

I currently am able to use audioPlayerRecorder to playback on the RME device and capture a single reference mic at the same time. In the same while loop as the audioPlayerRecorder call, I also have the miniDSP setup using audioDeviceReader and DirectSound driver. This method "works," but the playback and capture are both quite unstable and I'm getting lots of overruns and underruns.

[Jimmy Lapierre]

audioPlayerRecorder is ASIO only on Windows, but you can specify "Driver" with audioDeviceReader and Writer.

I think there's an issue here with two devices, as they'll never be perfectly in sync, one might be at 44100.1 Hz and the other at 44099.9 Hz. Eventually the faster one will underrun because you'll block/wait too long on the slower one waiting to get an audio buffer back (like every X number of frames).

[Michael Sonnenberg]

Yeah, I agree. Somehow I imagine they would need to be synced to the same clock.

I was succesfully able to capture recordings using the ASIO for playback and WASAPI for capture, but attempting to calculate Time of Arrival delays is likely not going to improve with this setup. I'm using a stimulus of 0.5 seconds of silence then 0.5 second 1kHz pilot tone. I then cross-correlate the captured audio with the stimulus and find where the maximum value occurs. Repeating the same exact measurement 40 times I'm calculating a mean delay of 600ms (this includes the 0.5s silence, so 500ms would be instantaneous) and a standard deviation of ~6.5ms, which is honestly pretty good using two separate devices and drivers, but just not quite good enough to distinguish mics that are centimeters apart.

I appreciate your help on this topic. I think at this point I'm just running into the limitations of my setup.

[Jimmy Lapierre]

In cases where latency changes every run like that, you need to do something similar to what the Impulse Response Measurer app does, which is measure latency and IR without interruption (one quick sweep to measure latency, silence, a measurement sweep, silence). Probably better to also record all mics at the same time using the same device.

Did you try using ASIO4ALL and setting it up to use your two devices? If that works, you could just use audioPlayerRecorder (ASIO).

[Rich Herr]

Hi Michael...ex-Leaper here. Say hi to Mark and Joel for me.

I've had some luck with Matlab Parallel toolbox for similar stuff, but I'm not sure if it'll get you both cards as ASIO and you'll probably still have some version of varying delay and needing to time sync with xcorr or impulse response.