Voicemeeter Virtual AISO Driver

[Bryan Rambo]

Hi All,

I am a minor (very minor) contributor to Thetis, an open-source software defined radio transceiver application used by ham radio operators around the world (openhpsdr.org). We are having trouble writing code to interface our application's receiver audio output stream to the Voicemeeter Virtual ASIO driver. The OutputDebugString() dump (shown below) indicates that we are successfully loading and initializing the driver, but our code can't seem to pass audio:

VM.jpg (156.57 KiB) Viewed 8976 times

Our code is successfully streaming audio to other common ASIO drivers (e.g. UMC ASIO Driver, Studio 192 ASIO, Focusrite USB ASIO, ASIO Lynx, etc.), so I was wondering if there's something special about the Voicemeeter driver that we are not addressing? Or maybe there's an SDK we can take advantage of? Advice please?

Thanks!

Bryan

[Vincent Burel]

could you please post a screenshot of Voicemeeter System Settings Dialog box?

Voicemeeter is usually not able to synchronize its virtual ASIO driver below 128 sample buffer size.
we recommend to use 256 samples buffer on Voicemeeter main stream to get a secure and stable audio stream on our virtual ASIO device.

[Bryan Rambo]

Thanks Vincent,

Here is the settings dialog box:

VoicemeeterOptions.jpg (72.57 KiB) Viewed 8947 times

I will try having our application initialize the Voicemeeter virtual ASIO driver to use 256 sample buffers, to see if that helps.

Also, I was wondering if the Voicemeeter virtual ASIO driver requires the client application to pass a valid Windows handle as the *sysRef argument in the ASIOInit() function parameter? Our application currently does not argue that parameter.

Thanks,

Bryan

[Vincent Burel]

yes, 64 sample buffer is surely too small. you may start with 256 or 512 samples buffer on Voicemeeter Main Stream.
(basically 5ms has to be considered as a minimum time cell under windows for getting stable real time audio).

Also you have defined the Virtual ASIO TYPE to Int32LSB which an option for old app . Today everybody uses Float32 instead.

no, SysRef argument is not used in our ASIOInit() function .

[Bryan Rambo]

Hi Vincent,

After further troubleshooting I have another clue, if you will be so kind to indulge.

I can see that ASIOStart() is returning ASE_OK from your virtual asio driver, but our bufferSwitchTimeInfo() callback is never called by the virtual asio driver. Are there additional handshaking steps that are needed to get the stream started? Can you suggest any driver inquiry calls that I can make to troubleshoot further?

Thanks,

Bryan

[Vincent Burel]

difficult to say without any information about your program
do you follow the ASIO Host Sample implementation example given by Steinberg.
Is this ASIO Host Sample example works with our driver ?

[Bryan Rambo]

Yes, I just tried it, hostsample.exe runs normally with ASIO_DRIVER_NAME defined as "Voicemeeter Virtual ASIO". So that was a good suggestion, thanks for that! Our program's ASIO interface is based directly on hostsample.cpp from the Steinberg SDK, but apparently I have made some change that has broken it for your driver. It's interesting though, our ASIO interface works fine with all the other ASIO device drivers I have tried. So there must be something I have overlooked with respect to your driver. I will trace through hostsample.cpp and see if I can find the missing step.

Also, just to be clear, your virtual ASIO driver is okay with Int32LSB sample format type, correct? (Even though Float32 is preferred.)

Thanks,

Bryan

[Vincent Burel]

yes the int32LSB should work, but maybe you will have to relaunch Voicemeeter or something like this.

ok, thanks to let me know what it is different in your implementation, compared to ASIO HOST Example.

[Bryan Rambo]

I have found the source of my problem. Earlier I had said that our application's callback (bufferSwitchTimeInfo) was not being called by the virtual ASIO driver, which was incorrect. Actually it WAS being called by the VAIO driver, but only for a very brief time, a hundred or so calls, after which the calls would suddenly stop.

It turns out that the culprit was PortAudio! Our application, in a different area from where I am working, uses PA to run streams of data for various digital radio modes (FT8, JT1, MAP65, etc.). So during program startup, after our ASIO connection is made with the virtual ASIO driver, a call is being made to Pa_Initialize() in the PortAudio library which immediately causes our stream to the virtual ASIO driver to fail!

So my temporary workaround is to inhibit the call to Pa_Initialize(), which allows our voice mode audio to stream beautifully (both transmit and receive) to the virtual ASIO driver But this, of course, disables the function of the part of the application that depends on PortAudio.

Would you have any advice for me on how to allow our streaming to the virtual ASIO driver to survive a subsequent call to Pa_Initialize()? Would there be a way, perhaps, to put the virtual ASIO driver into an "exclusive mode" that would not allow it to be taken over by PortAudio?

Thanks for your kind assistance!