RPI4 Trifecta: VARA, Packet & ARDOP – One Audio Interface

Requirements

Update 2022/08/15 I have created an image for RPI4 systems, documented here.

This document assumes you have already installed the VARA suite of modems and the companion programs via the Winelink project. If not, now is your chance-

Word of caution: installing wine is disk intensive, if you have not yet got your home directory on a real physical disk instead of the SD Card- now is the time to consider doing that. The SD Card is also incredibly slow for wine applications.

To install Wine and the ARM x86 emulator system, visit the Winelink GitHub page.

Or go wild and run it live from the command line:

curl -O https://raw.githubusercontent.com/WheezyE/Winelink/main/install_winelink.sh && \
     bash install_winelink.sh

VARA: dsnoop & dmix

This part of the document is a breakdown of the .asoundrc config file, for the complete file skip to the Complete Config File, but be mindful that the config file is only a small part of the process as there are also steps to be taken in the Windows registry editor.

Physical audio interface mapping to the virtual sound devices for playback (dsnoop) and recording (dmix), the device shown below- “hw:1,0” refers to the audio interface ID provided by the ‘aplay -l’ command. Yours may differ. E.g. hw:2,0 etc.

pcm.dsnooped0 {
     type dsnoop
     ipc_key 50000
     ipc_key_add_uid false # let multiple users share
     ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
     slave {
           pcm "hw:1,0"
           channels 1
           }
}

pcm.dmix0 {
     type dmix
     ipc_key 60000
     ipc_key_add_uid false # let multiple users share
     ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
     slave {
           pcm "hw:1,0"
           rate 44000
     } 
}

Both VARA and ARDOP require 48KHz sample rate to be forced (default is 44.1 for system sounds) so two new audio streams are required and this is accomplished using the .asoundrc file configuration.

Below is a snip showing the previously configured dsnoop0 & dmix0 interfaces, we’re going to call them ARDOP2IN and ARDOP2OUT.

pcm.ARDOP2IN {type rate slave {pcm "plug:dsnooped0" rate 48000}}
pcm.ARDOP2OUT {type rate slave {pcm "plug:dmix0" rate 48000}}

Wine (for VARA) requires these 48KHz audio device streams, but in a slightly different presentation to the system. Wine requires asymmetrical streams that we currently do not have, these are provisioned by combining the two previously configured ARDOP streams into a new virtual device “asymwine”.

pcm.asymwine { 
        type asym 
        playback.pcm "ARDOP2OUT" 
        capture.pcm "ARDOP2IN"
} 

pcm.!default { 
        type plug 
        slave.pcm "asymwine" 
} 

pcm.dsp { 
        type plug 
        slave.pcm "asymwine" 
} 

The next bit gets hairy as we are now required to edit the Wine Registry- what happens is that ‘winecfg’ enumerates (gathers) what it can glean from the host operating system about the audio drivers, unfortunately this process does not scrape the .asoundrc file so this particular gotcha requires a couple of new entries in the registry to be made by hand.

Run from the command line:

wine regedit

In the registry editor, navigate to:

HKEY_CURRENT_USER\Software\Wine\Drivers\winealsa.drv

From within winealsa.drv, create a new “Multi-string value”.

Name this key:

ALSAOutputDevices

Hit enter to save, then create another key and title it:

ALSAInputDevices

After adding the keys, double-click each newly created key to open it in data entry mode. Insert the device name previously configured in the .asoundrc file – asymwine, do this for BOTH ALSAOutputDevices and ALSAInputDevices.

Close the registry editor and relax.

Now run “winecfg” again and navigate to the Audio tab, from the list of each input/output it should now be possible to select the newly appearing “asymwine” audio interface. If all things went to plan, be sure to do this action for each of the 4 fields.

Apply, OK and exit winecfg.

Open up VARA HF and navigate to sound settings to select the asymwine interfaces.

The VARA application by default takes on Windows appearance. To make it look like a native application, head into the winecfg settings and select from the Graphics tab: Allow the window manager to control the windows.

This concludes the VARA part.

---

Download & Resources for QtSoundModem & ARDOP

QtSoundModem: https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html

ARDOP: https://www.cantab.net/users/john.wiseman/Documents/ARDOPC.html

QtSoundModem (Packet)

We are assuming that piQtSoundModem has already been set up using a regular audio interface and all of your options and modem settings are ready- if not, go do that first.

To configure QtSoundModem to use the dsnoop0/dmix0 device the INI file has to be edited manually, any changes made with the GUI of QtSoundModem will overwrite your manual changes and break your setup, so consider fixing the permissions on the INI file so that it can’t write to the file, using “chmod 444 QtSoundModem.ini”

Edit QtSoundModem.ini:

Find and replace the SndRX/TX lines:

SndRXDeviceName=:dsnooped0
SndTXDeviceName=:dmix0

That concludes the QtSoundModem setup.

ARDOP

Using a script to launch piardopc, tailored to your own system, below is an example.

/home/pi/bin/piardopc 8515 ARDOP2IN ARDOP2OUT

8515 is the port ARDOP will listen for TNC connections on (as used when configured in BPQ node suite etc).

ARDOP2IN and ARDOP2OUT are the virtual interfaces previously configured in .asoundrc to provision the required 48KHz sample rate streams.

This concludes the ARDOP setup.

Complete Config file & Credits

Thanks and credit due to Matt KB8UVN & Steve G7TAJ for the initial annotated .asoundrc dsnoop/dmix syntax that got the ball rolling, and WheezyE/Winelink (on GitHub) for the massive effort getting VARA to run on the Pi in the first place.

Below is the full .asoundrc file that works for me:

@hooks [
         {
                 func load
                 files [
                         {
                                 @func concat
                                 strings [
                                         { @func datadir }
                                         "/alsa.conf.pulse/"
                                 ]
                         }
                 ]
                 errors false
         }
 ]

# Point applications to plughw:dsnooped0 for input and plug:dmix0 for output

pcm.dsnooped0 {
    type dsnoop
    ipc_key 50000
    ipc_key_add_uid false   # let multiple users share
    ipc_perm 0666           # IPC permissions for multi-user sharing (octal, default 0600)
    slave {
        pcm "hw:1,0"
        channels 1
    }
}

pcm.dmix0 {
    type dmix
    ipc_key 60000
    ipc_key_add_uid false   # let multiple users share
    ipc_perm 0666           # IPC permissions for multi-user sharing (octal, default 0600)
    slave {
        pcm "hw:1,0"
        rate 44000
    }
}

# Point ARDOP to ARDOP2IN and ARDOP2OUT for rate conversion

pcm.ARDOP2IN {type rate slave {pcm "plug:dsnooped0" rate 48000}}
pcm.ARDOP2OUT {type rate slave {pcm "plug:dmix0" rate 48000}}


# Wine: combine the capture and playback 
pcm.asymwine { 
        type asym 
        playback.pcm "ARDOP2OUT" 
        capture.pcm "ARDOP2IN"
} 

# Wine: make a default plug for it 
pcm.!default { 
        type plug 
        slave.pcm "asymwine" 
} 

# Wine: define a plug for /dev/dsp 
pcm.dsp { 
        type plug 
        slave.pcm "asymwine" 
} 

Appendix: PTT

At some point in the future, I will try to delve into the issue of serial PTT signal mixing for those not using a VOX-enabled setup like myself (yay Signalink). This is a complicated problem with a complex solution that needs considerable time to look in to for Linux.

• BPQ32 Rig Control – VOX and/or CAT PTT

Appendix: Applications as a system Service

• VARA, ARDOP and QtSoundModem as System Services

Appendix: Stabilizing VARA

• VARA Linux – Keeping the TNC alive