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!
Audio
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:
Setting up the network
If your VM is using NAT, the VM is not reachable from the local network, despite having internet. You will have to use a bridged network to have the VM in the local network and to be able to communicate. Here's a tutorial on how this can be configured on ubuntu 22.04 using KVM (QEmu): https://fabianlee.org/2022/09/20/kvm-creating-a-bridged-network-with-netplan-on-ubuntu-22-04/
TX-Stream (Windows VM to Linux Host)
There's a piece of ready to use software around, that does exactly what we need: https://github.com/duncanthrax/scream
Windows side (Win 10) / Server:
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:
pacmd list-sinksNow, we're set up to start the receiver. This is how the command looks like on my system:
scream -i br0 -s alsa_output.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00.analog-stereoTX ready! Test it by sending a beacon to your dummy load an listen to your TRX Monitor.
RX-Stream (Linux Host to Windows VM)
Linux side / Server:
For the RX stream, ffmpeg is used. It's available for Linux and Windows, and well maintained. What we do is just pipe the raw sound at alsa level to ffmpeg which streams it.
First, we need to find out the alsa name for the soundcard. In my case that's hw:CARD=Device,DEV=0. You can get a list of available alsa devices with the following command:
aplay -LThen we need to know the IP of the Windows client (192.69.178.10 in this example) and choose a high port (here: 34567).
Now, we can start the server:
arecord --quiet -D hw:CARD=Device,DEV=0 -f S16_LE -r 44100 | ffmpeg -re -i - -f s16le udp://192.168.178.100:34567If everything is fine, you should see running numbers now. Every now and then an error may occur, you may gracefully ignore it.
Adding an encoder to the pipe: arecord options | lame --silent -r -m m - | ffmpeg options gets rid of that errors, but may introduce latency.
Windows side (Win 10) / Client:
FFMpeg does not come shipped with Windows, so you will have to download and install: https://www.ffmpeg.org/download.html.
Here's an example on how to start the ffplay client. You will have to change the IP to the IP of the Linux host.
ffplay.exe -f s16le -ar 44100 -ac 1 -i udp://192.168.178.50:34567For 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.