Hello folks, Thought to contribute to the group with a recent success of getting a RPI to take over doing all of the things at once on one audio interface including VARA running simultaneously as other native Linux modems:
The original document with images and a demo video is up here:
¡ª- included below for archival ¡ª-
RPI4 Trifecta: VARA, Packet & ARDOP ¨C One Audio?Interface
A Short Demonstration
Requirements
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?
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.
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.
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.
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 ¨C?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?asymwineinterfaces.
This concludes the VARA part.
Download & Resources for QtSoundModem & ARDOP
QtSoundModem:?
ARDOP:?
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.
Full disclosure
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"
}