Edit: After some more testing, it seems to me, that the described setup does not work as good as expected. While the method works fine for receiving and I did have some connections without problems, in other cases the Vara connections do not establish while the stream is running fine. Maybe UDP audio streaming is not a good idea at all for Vara. Please consider this post experimental.
This post may help users that have a linux hamstack running and want to be able to switch quickly to VaraC which is running in a virtual machine on the same host. VaraC does run under Linux, using wine, that's not covered here. The described setup allows to switch to VaraC on the fly, just by setting the frequency. If your linux hamstack includes various programs like FLDigi, JS8, WSJTX and you use them quickly one after another, this might be for you. I do have an SDR Device, running from the intermediate frequency output of my TRX, so I'm able to watch the waterfall, decode interesting signals and switch to the desired mode by presetting the according frequency on VFO-B, switch to VFO-B and return when done.
For this integration we need to look at four controls: CAT, PTT, TX audio and RX audio.
CAT and PTT
With FLRrig support this is now a piece of cake. Just point VaraC settings to your FLRig instance and it should work fine. Thanks, Irad!
There are different options to get the audio from the host to the VM and vice versa.
* VM Software has an implemented way to pass sound from client to host. If this is an option: Go with it.
* You can pass the USB device of your rig soundcard to the VM. This is a good option. The only downside is, that you'll have to pass the device everytime you're switching apps. You might have to configure the sound settings in the apps, as well.
* You may use two additional USB soundcards, wire mic-to-speaker, give one card to the host and one to the VM and software wire the according outputs using e.g. Jackaudio / VirtualCable. There's no practical downside to that solution other than it's hardware and even more cables on the desk.
* The way described here makes use of the network interface: UDP streaming. Please keep in mind, that UDP does not guarantee receiving the packet in the right order or receiving at all. That may lead to distortion or drop-outs. On my local setup, that has not imposed any problems (maybe it did, still analyzing). I would not recommend this setup over WAN, though.
There are always other other ways and different programs may be used. Using OBS might be a good alternative. Like always: There is room for improvement. Comments are appreciated.
To stream audio from host to VM, we need a server and a client for each RX and TX. Here's how it can be done:
The software presents as a driver which can be found at:
Device-Manager -> Sound, video and gamecontrollers
The driver creates a virtual audio device, that streams our audio. Setting are done in windows:
Settings -> Sound -> Output - set Output Device to Speakers (Scream WDM) -> Device Properties -> Related Settings / Additional Device Properties => Opens Window Speakers Properties -> Tab Advanced lets you set the default format. Set it to 32 bit 48000 Hz
Now, you can got to Vara (Modem) Sound Settings and choose Speakers(Scream (WDM)) as output.
Linux side / Client:
Compile the receiver according to the readme on the github page of scream. The command takes two parameters:
1) The network device, that is used by the VM. In my case, that's br0, the network bridge at system level of the host which is described above.
2) The pulseaudio name for the soundcard, the signal is going to. You can get a list of available cards with the following command:
Now, we're set up to start the receiver. This is how the command looks like on my system:
For convenience, create a .cmd file to start the client. You may have to use the full path to ffplay.exe, or point the PATH Variable to the ffmpeg directory.
If everything is fine, you can now hear the RX audio at the speakers of your Windows VM.
To get the sound into the Vara modem, we have to put it into a virtual sound device. I used Voicemeeter for that task: https://vb-audio.com/Voicemeeter/. This might be a bit of an overkill, but it's convenient and free for personal use.
To get the audio to the virtual sound device, windows configuration is used. An application named udp://yourhostIP:34567 shoud show up here, while the client is running: Settings -> Sound -> Advanced Sound Options / App volume and device preferences
Set the output of that application to input of your virtual sound device.
Finally, set the input of the Vara modem sound settings to the output of your virtual sound device.
Done! VaraC should be able to send and receive, while other software is connected to your hamstack.
Having more than one client being able to send at the same time, requires all clients to remain silent until the operator wants them to send. Better turn beacons off, while doing other stuff.