Ich verwende schon länger für SVXLINK USB-Soundkarten mit CM108 bzw. CM108B Soundchips. Diese kann man für ca. 7€ im Handel erwerben. Vorteil ist, diese Soundchips verfügen über eigene GPIO-PINs, so dass eine PTT-Steuerung und eine SQL-Signalauswertung direkt mit diesen Soundkarten möglich ist, was von SVXLINK auch unterstützt wird (via HID_RAW_DEVICE).

Diese USB-Soundkarten werden von Linux nativ erkannt, man muss keine extra Kernel-Module laden/compilieren.

Allerdings muss man diese Karten ein wenig modifizieren, was für den geübten Funkamateur aufgrund der offenen Bauweise aber kein größeres Problem darstellt.

Eine entsprechende Umbauanleitung kann man hier finden. Auch in den SHARI-Hotspots von Aliexpress kommen CM108B-Soundchips zum Einsatz (neuere Ausführung CM108B, aber 100% kompatibel mit CM108).

Immer wieder lese ich in diversen Quellen und Foren in Zusammenhang SVXLINK solche Aussagen wie "Ursache meiner Probleme war eine USB-Soundkarte, nach dem Tausch war das Problem weg.". Ich kann bis heute keinen driftigen Grund für diese Aussagen finden, sowas gehört für mich ins Reich der Märchen und Sagen. Fakt ist, konfiguriert man das Linux korrekt für diese Soundkarten, nutzt aktuelle Versionen vom SVXLINK und natürlich auch eine aktuelle Linux-Plattform, gibt es keine bekannten Probleme beim Einsatz dieser USB-Soundkarten. Ich habe selber an einigen Relais in Kombination mit einem YAESU DR1XE bzw. HYTERA RD985 genau diese umgebauten USB-Soundkarten im Dauereinsatz und noch nie sind irgendwelche Probleme aufgetreten, die auf diese USB-Soundkarten zurückzuführen gewesen wären.

Getestet bzw. im Einsatz mit folgenden Geräten:

• YAESU DR1XE (DB0SPB, DO0BRB, DL1BZ-R)
• HYTERA RD985 (DL1BZ-R)
• MOTOROLA GM340 (DB0BIW)
• FM-TRX-Module DRA/SA818-U bzw. -V (FM-Simplex-Repeater, SHARI-Hotspots von Aliexpress)
• YAESU FTM100DE (FM-Simplex-Repeater)
• YAESU FTM300DE (FM-Simplex-Repeater)

getestetes Linux-OS: Raspian/Debian11 (Bullseye) auf Raspberry Pi 2B, 3B, 3B+

In aktuellen Raspian/Debian-Versionen wird die USB-Soundkarte meistens nicht als Device 0 (default) gelistet, sondern als Device 1. Grund ist eine Regel bzw. Definition in der mitgelieferten /lib/modprobe.d/aliases.conf , da man das on-board Sounddevice, was leider nur einen Audio-OUT und keinen Audio-IN besitzt, immer als Device 0 setzen will. Wir benötigen allerdings dieses on-board Audiodevice nicht, deswegen werden wir es deaktivieren und unsere USB-Soundkarte als Device 0 per Default definieren.

Dafür ist unbedingt die /lib/modprobe.d/aliases.conf anzupassen ( übersteuert leider die /etc/modprobe.d/aliases.conf , auch wenn man es dort definieren würde, was normalerweise der richtige Weg wäre !):

...
# options snd-usb-audio index=-2
...

/boot/config.txt anpassen:

# HDMI Audio deaktivieren
dtoverlay=vc4-kms-v3d,audio=off
# Enable on-board audio (loads snd_bcm2835)
# brauchen wir nicht deswegen auskommentieren entspricht OFF
# dtparam=audio=on

Kontrolle, ob es geklappt hat:

$ sudo cat /proc/asound/modules
 0 snd_usb_audio

Jetzt ist die USB-Soundkarte als Device 0 und damit als Default-Device geladen. Das on-board Sounddevice wird nicht angezeigt, denn wir haben es ja deaktiviert, gleiches gilt für das HDMI-Audio.

Wir prüfen mal unseren USB-Bus:

$ sudo udevadm info /dev/bus/usb/00x/00x
$ sudo udevadm info -a /dev/bus/usb/00x/00x
$ sudo udevadm monitor --subsystem=sound

Restart udev

$ sudo /etc/init.d/udev restart

Wenn alles klar, dann /etc/udev/rules.d/90-cm108.rules neu anlegen mit folgendem Inhalt:

# block pulseaudio using the USB soundcard based CM108 for SVXLINK
ATTRS{idVendor}=="0d8c", ENV{PULSE_IGNORE}="1"
#
#   nur bei Raspberry Pi
#
#   DEVPATH ist System-spezifisch und auf JEDEM System erneut anzupassen
#   Angabe DEVPATH aus udevadm info -a /dev/bus/usb/00x/00x extrahieren
#
#   ######### ############### ###############
#   #       # # cm108gpio1  # # cm108gpio2  #
#   #       # # CM108-USB1  # # CM108-USB2  #
#   # eth0  # ############### ###############
#   #       # # cm108gpio3  # # cm108gpio4  #
#   #       # # CM108-USB3  # # CM108-USB4  #
#   ######### ############### ###############
#
# USB links oben
SUBSYSTEM=="hidraw", ATTRS{devpath}=="1.1.2", ATTRS{idVendor}=="0d8c", SYMLINK+="cm108gpio1", MODE="0666"
SUBSYSTEM=="sound", ATTRS{devpath}=="1.1.2", ATTRS{idVendor}=="0d8c", ATTR{id}="CM108-USB1"
# USB rechts oben
SUBSYSTEM=="hidraw", ATTRS{devpath}=="1.3", ATTRS{idVendor}=="0d8c", SYMLINK+="cm108gpio2", MODE="0666"
SUBSYSTEM=="sound", ATTRS{devpath}=="1.3", ATTRS{idVendor}=="0d8c", ATTR{id}="CM108-USB2"
# USB links unten
SUBSYSTEM=="hidraw", ATTRS{devpath}=="1.1.3", ATTRS{idVendor}=="0d8c", SYMLINK+="cm108gpio3", MODE="0666"
SUBSYSTEM=="sound", ATTRS{devpath}=="1.1.3", ATTRS{idVendor}=="0d8c", ATTR{id}="CM108-USB3"
# USB rechts unten
SUBSYSTEM=="hidraw", ATTRS{devpath}=="1.2", ATTRS{idVendor}=="0d8c", SYMLINK+="cm108gpio4", MODE="0666"
SUBSYSTEM=="sound", ATTRS{devpath}=="1.2", ATTRS{idVendor}=="0d8c", ATTR{id}="CM108-USB4"

Jetzt haben wir, je nachdem in welchem USB-Port des Pi die USB-Soundkarten stecken, entsprechende symbolic Links auf die zugehörigen HID_RAW_DEVICEs /dev/hidraw[0-3] :

/dev/cm108gpio1 (USB Port oben links, ALSA-Device-Alias CM108-USB1)

/dev/cm108gpio2 (USB Port oben rechts, ALSA-Device-Alias CM108-USB2)

/dev/cm108gpio3 (USB Port unten links, ALSA-Device-Alias CM108-USB3)

/dev/cm108gpio4 (USB Port unten rechts, ALSA-Device-Alias CM108-USB4)

Das erspart uns das Suchen, welches HID_RAW_DEVICE zu welcher USB-Soundkarte gehört und wir können es gezielt in der svxlink.conf verwenden.
Für die umgebauten CM108 gilt folgendes Setup SVXLINK:

[Rx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:CM108-USB[1..4]
AUDIO_CHANNEL=0
SQL_DET=HIDRAW
HID_DEVICE=/dev/cm108gpio[1..4]
# je nach Logic Active Low oder Active High
# HID_SQL_PIN=VOL_DN
HID_SQL_PIN=!VOL_DN
PREAMP=0
PEAK_METER=1

[Tx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:CM108-USB[1..4]
AUDIO_CHANNEL=0
PTT_TYPE=Hidraw
HID_DEVICE=/dev/cm108gpio[1..4]
# je nach Logic Active Low oder Active High
# HID_PTT_PIN=!GPIO3
HID_PTT_PIN=GPIO3
MASTER_GAIN=0

Bei Problemen mit alsactl die Datei /var/lib/alsa/asound.state löschen und

$ sudo alsactl store

ausführen. Datei wird neu angelegt.

$ sudo aplay -L
$ sudo alsamixer -D hw:CM108-USB4

[Rx1]
TYPE=Local
RX_ID=R
AUDIO_DEV=alsa:plughw:CM108-USB3
# AUDIO_DEV=alsa:plughw:0

[Tx1]
TYPE=Local
TX_ID=T
AUDIO_DEV=alsa:plughw:CM108-USB3
# AUDIO_DEV=alsa:plughw:0

Normalerweise ist diese Maßnahme nicht(!) erforderlich und nur in ganz speziellen Ausnahmefällen anzuwenden, auch nicht als "Vorsorgemassnahme". Aktuell war das bisher nirgends erforderlich, obwohl in der Vergangenheit in Zusammenhang mit USB-Soundkarten diese Empfehlung gelegentlich publiziert wurde - möglicherweise gab es früher Probleme mit der Pi-Firmware bzw. älteren Linux-Kernel-Versionen und dem Pi-USB-Bus. So ganz klar war das nie.

Wir ändern/ergänzen in der /boot/cmdline.txt folgendes:

dwc_otg.speed=1

73 Heiko, DL1BZ