Capturing my setup for VAC audio without intermittent clicks etc...
| Component | description |
|---|---|
| OS | Ubuntu 22.04 |
| RAM | 128GBs (way overspec'd) |
| CPU | AMD Ryzen Threadripper 16 cores / 32 Threads |
I used a laptop with hackrf and software gqrx - this also shows a waterfall for the demodulated audio. I placed this in another room (far from the shack) and accessed using ssh setup to allow the gqrx GUI to be tunneled back to me remotely.
The receiver was heavily attenuated by simply having no antenna connected, with strong signals this was further attenuated with a 50ohm terminator. This is to ensure no rf distortion on receive.
aptitude install linux-lowlatency-hwe-22.04
This step gave a significant improvement in the reduction of dropouts / clicks.
pulseaudio -k
options snd-hda-intel vid=8086 pid=8ca0 snoop=0 power_save=0
alias snd-card-0 snd-aloop
options snd-aloop enable=1,1,1,1,1 index=10,11,12,13,14 pcm_substreams=1,1,1,1,1
This actually creates 5 loopback virtual soundcards in the kernel, indexed as 10, 11, 12, 13 and 14. (I actually only currently use 2 of them in ExpertSDR2)
ctl.mixer0 {
type hw
card 0
}
pcm.!default {
rate 48000
}
defaults.pcm.rate_converter "samplerate_best"
--- ../../../../TARs/qsstv_9.4.4/qsstv/sound/soundalsa.cpp 2019-05-20 11:02:11.000000000 +0100
+++ soundalsa.cpp 2020-09-03 12:07:19.655075615 +0100
@@ -365,7 +365,7 @@
!deviceName.contains("surround",Qt::CaseInsensitive)
&& !deviceName.contains("dmix",Qt::CaseInsensitive)
&& !deviceName.contains("front",Qt::CaseInsensitive)
- && !deviceName.contains("plughw",Qt::CaseInsensitive)
+ //&& !deviceName.contains("plughw",Qt::CaseInsensitive)
&& !deviceName.contains("null",Qt::CaseInsensitive)
&& !deviceName.contains("hdmi",Qt::CaseInsensitive)
&& !deviceName.contains("sysdefault",Qt::CaseInsensitive)
This simply enables the plughw: devices to be listed and selectable from the alsa devices config menu.
| Setting | Value |
|---|---|
| RX | Alsa: Loopback: PCM (hw:10,0) |
| TX | Alsa: Loopback: PCM (hw:11,1) |
| Sample Rate | 48kHz |
| Buffer | 2048 Samples |
| RX gain | -9dbB |
| TX gain | -10dB |
The "TX gain" should be fine tuned using a heavily attenuated receiver - to ensure no audio distortion / harmonics.
ExpertSDR2 has to be started up and the VAC enabled before starting any data modem software to ensure it gets "Ownership" of the audio loopback devices (it complains otherwise).
(see update below, i'm not using this anymore. However, enabling rtprio for your user may prepare your system for any future realtime improvements/support in ExpertSDR2)
@realtime - rtprio 99
@realtime - memlock unlimited
add your login user to be a member of group realtime.
#!/bin/sh -x
BASE_DIR=$(dirname "$(readlink -f "$0")")
export LD_LIBRARY_PATH="$BASE_DIR"//lib/:"$BASE_DIR":$LD_LIBRARY_PATH
export QML_IMPORT_PATH="$BASE_DIR"//qml/:QML_IMPORT_PATH
export QML2_IMPORT_PATH="$BASE_DIR"//qml/:QML2_IMPORT_PATH
export QT_PLUGIN_PATH="$BASE_DIR"//plugins/:QT_PLUGIN_PATH
export QTWEBENGINEPROCESS_PATH="$BASE_DIR"//bin//QtWebEngineProcess
export QTDIR="$BASE_DIR"
export QT_QPA_PLATFORM_PLUGIN_PATH="$BASE_DIR"//plugins//platforms:QT_QPA_PLATFORM_PLUGIN_PATH
#chrt -v 99 "$BASE_DIR"//bin/ExpertSDR2 "$@"
"$BASE_DIR"//bin/ExpertSDR2 "$@"
Note the chrt -v 99 ... I added at the end.
Update 2020-10-31: I reverted the chrt -v 99 ... back to normal scheduling, as according to this
ONLY the audio I/O thread and if you do MIDI , the MIDI thread too, MUST run SCHED_FIFO... without SCHED_FIFO you will not get reliable low-latency.
all other threads should run with normal scheduling policy so that if the audio/midi thread needs the CPU, it will get the processing power even if you do heavy disk I/O or heavy CPU work in the background.
Last I checked ExpertSDR2 has 97 threads, so I dont think it is advisable for them all to have realtime priority scheduling.
Doing a ps -eflLc | egrep -i "(UID|expert)" I dont see any threads running realtime priority - maybe there is room here for
ExpertSDR2 to be improved...
Update 2020-12-18: Trying running ExpertSDR2 with nice value of -20, so it gets a higher dispatching priority. Launcher:
sudo nice -n -20 -- su your_user -c /usr/local/ExpertSDR2/ExpertSDR2_1.3.1_Update5_SunSDR2_Ubuntu_x64/ExpertSDR2.sh
I experienced a momentary audio blip at the start of each transmission in any digi mode - I noticed the tone was always the same as the last tone sent in the previous transmission. Seemed like the transmission was being stopped before all the audio buffer was sent, and was still a bit buffered on the next transmission.
Setting Options->Device->TX tab->PTT switching delay->Tx to Rx = 75 ms fixed this for me.
Upgraded from Update5 to Update8 (with firmware upgrade).
Experienced the zero power on TX issue - fixed by simply re-writing power settings in Options -> Device -> Expert.
Initial tests of audio quality show that the intermittent clicks have now gone.