OpenHPSDR-Thetis und cmASIO

Heute wollen wir uns mal einem Thema in Zusammenhang mit OpenHPSDR-Thetis widmen, was vielen vielleicht nicht so bekannt ist. Es soll um die Möglichkeit gehen, ein Audio-Interface direkt per ASIO an Thetis anzubinden. Doch um alles besser zu verstehen, erstmal etwas Theorie.

Was ist ASIO ?

Unter Windows ist ASIO quasi DER Software- und Hardware-Standard für echtzeitfähige Klangverarbeitung. Es ist ein von Steinberg Media Technologies entwickeltes, mehrkanalfähiges Audiotransfer-Protokoll.

In den meisten Betriebssystemen wie WINDOWS, Linux oder macOS hat man für die Verarbeitung von Audiodaten sog. API („Application Programming Interface“) definiert, damit die Programmierer entsprechender Anwendungen nicht auf unterer Betriebssystemebene erst Programmcode schreiben müssen, um z.B. Audio auf vorhandenen Soundkarten oder anderen Soundinterfaces ausgeben zu können oder aufzunehmen.

Hier einige Beispiele für solche System-APIs:

• WINDOWS: MME, WDM / DirectSound, KS
• macOS: CoreAudio
• Linux: ALSA

Da hier das gesamte Audioprozessing durch diese APIs läuft, bedingt das zwangsläufig gewisse Laufzeiten der Datenströme, die auch Latenzen genannt werden. Innerhalb dieser APIs können auch Eingriffe in den Audio-Datenstrom erfolgen, wie z.B. Bitratenkonvertierung, wenn meine Software mit 48kHz Samplingrate arbeitet, meine Soundkarte aber nur 44.1kHz verarbeiten kann. Diese Aufgaben übernehmen diese APIs, da muss sich also der Programmentwickler nicht direkt darum kümmern. Das alles ist, wie bereits gesagt, mit einem gewissen Zeitversatz verbunden, denn diese Aufgaben benötigen etwas Zeit, um solche Datenströme „umzuarbeiten“. Das kann, je nach API, schon mal in den höheren Millisekundenbereich gehen. Es bedeutet aber nichts anderes, als das der Zeitpunkt, wo ein Ton erzeugt wird, zeitlich versetzt mit dessen Wiedergabe, z.B. aus einem Lautsprecher, liegt. Ähnlich wie ein Echo also. Das hört man aufgrund von Laufzeiten (Latenzen) auch erst später im Vergleich zu seinem Ursprung.

Signalverarbeitung benötigt Zeit – Problem Latenz

Dieses Problem haben wir also bei unseren SDR-Systemen auch, bedingt durch die erforderliche digitale Signalverarbeitung. Wir empfangen ein Signal, dieses wird bei SDR durch einen ADC in einen digitalen Datenstrom konvertiert und dann zur weiteren Verarbeitung z.B. per Netzwerk wie beim Hermes Lite 2 oder per USB wie bei den SDRplay an die eigentliche SDR-Software übergeben. Damit haben wir schon mal die erste Verzögerung. Die Software übernimmt die Demodulation, macht also aus einem empfangenen SSB-Signal wieder einen hörbaren NF-Audiodatenstrom, den wir im entsprechenden Soundinterface wieder in ein Analogsignal mittels DAC „zurückverwandeln“ und dieses durch unseren NF-Verstärker auf die Lautsprecher oder Kopfhörer ausgeben können, damit unser menschliches Gehör das verarbeiten kann. Dazwischen erfolgt noch etwas Mathematik an dem Audiodatenstrom, denn wir lassen ja Filter (SSB-Filter, Notchfilter, Rauschunterdrückung etc.) anwenden, die erstmal gerechnet werden müssen.

Das Ganze muss natürlich quasi möglichst in Echtzeit erfolgen, die es aber nicht gibt bei digitaler Signalverarbeitung. Es kostet also Zeit, sprich wir haben eine Latenz bis das Signal die Lausprecher erreicht und damit unsere Ohren. Die Schallgeschwindigkeit lassen wir mal bei dieser Betrachtung beiseite, denn wir sitzen ja nicht auch noch hunderte Meter von den Lautsprechern entfernt. Anders als Funkwellen, die sich mit Lichtgeschwindigkeit ausbreiten, trifft das bei Schall nicht zu. Durch die uns umgebende Luft liegt diese bei etwa 343,2m pro Sekunde. Bedeutet, in 343m Entfernung erreicht uns der Schall schon mal 1s später im Verhältnis zu seiner Entstehung.

Unsere Betrachtung wird sich also im Millisekundenbereich bewegen, da wir nur den Durchlauf vom Empfang eines Signals von unserer Antenne bis zu seiner Wiedergabe auf unseren Lautsprechern betrachten werden bzw. den umgekehrten Weg vom Mikrofon bis zur Erzeugung eines HF-Signals, welches unsere Antenne wieder abstrahlt.

Jedes SDR-System hat also immer eine Grundlatenz, die einfach aufgrund der Analog-Digital-Wandlung bzw. Digital-Analog-Wandlung immer vorhanden sein wird. Wie schnell das alles geht, ist eine Frage von Übertragungswegen, also dem Transport dieser Daten, und die Verarbeitungsgeschwindigkeit, die durch die zur Verfügung stehende Rechenleistung begrenzt wird.

ASIO (Audio Stream Input/Output) widmet sich ausschließlich der NF-Seite, also die Übertragung digitalisierter niederfrequenter Signale wie u.a. unsere Sprache oder Musik, die sich ja in etwa zwischen 20Hz und 20kHz bewegen, also dem, was unser menschliches Gehör ohne Hilfsmittel direkt verarbeiten kann.

Thetis und cmASIO

cmASIO im Zusammenhang mit dem Hermes Lite 2, der das HPSDR-Protokoll in der Version 1 verwendet, setzt mindestens OpenHPSDR-Thetis in der Version 2.10.3.5 oder höher voraus. In älteren Thetis-Versionen wurde das für SDR-Geräte, die via HPSDR-Protokoll Version 1 kommunizieren, noch nicht unterstützt.
Die Version 2.10.3.5 ist bei Erstellen dieses Beitrags die aktuelle, offizielle finale Thetis-Version, obwohl bereits eine neuere Version 2.10.3.6 verfügbar ist – diese hat derzeit aber noch Beta-Status.
Zu finden ist Thetis für den Hermes Lite 2 unter https://github.com/mi0bot/OpenHPSDR-Thetis/releases .

OpenHPSDR-Thetis ist eine 64bit-WINDOWS-Applikation für SDR-TRX. Der Großteil der Signalverarbeitung findet also nicht im eigentlichen SDR-TRX wie dem Hermes Lite 2 statt, sondern in der SDR-Applikation. So auch das gesamte Audioprozessing. Per default unterstützt Thetis dabei alle gängigen Sound-APIs von WINDOWS, darüber hinaus aber auch Dinge wie eben ASIO. Die meisten Anwender werden also MME, DirectSound/WDM oder KS verwenden. Alle diese haben eines gemeinsam, nutzt man diese Sound-APIs, haben wir eine relativ hohe Latenz, die sich so zwischen 300-500ms bewegen wird.

cmASIO für Thetis wurde von W4WMT entwickelt und implementiert. Es ist gedacht für den Einsatz für Soundhardware mit echten ASIO-Treibern, also keinen „virtuellen“ wie ASIO4ALL oder ähnlichen „Ersatztreibern“, die zwar eine Art ASIO-Schnittstelle bereitstellen, aber nicht die Latenzzeiten erreichen können wie das bei echter ASIO-unterstützter Hardware der Fall ist.
Dazu gab es von dem Entwickler W4WMT auch ein klares Statement:

„Due to performance issues, cmASIO does not support virtual ASIO drivers.“ (W4WMT)

Die Latenz kann man einfach mal selbst prüfen, indem man – falls verfügbar – einfach mal ein älteres, wirklich analoges Funkgerät nimmt und parallel zum SDR-TRX mal die gleiche Frequenz einstellt und wiedergibt. Man wird feststellen, der Audio des SDR liegt zeitlich hinter dem des analogen TRX. Um wieviel, hängt eben von vielen Faktoren ab. Gleiches gilt natürlich auch im Falle, wenn wir senden. Unser Sendesignal des SDR liegt zeitlich ebenfalls etwas hinter dem des analogen TRX, wenn wir sprechen und uns gleichzeitig abhören würden.

Eine Möglichkeit, diese Latenz abzusenken oder zu verkürzen, wäre das Audio-Prozessing irgendwie schneller zu machen. Um das zu erreichen, müssen wir also die Sound-API des Betriebssystems umgehen und einen möglichst kurzen Weg zwischen der Ausgabe des Audiodatenstroms, den uns Thetis ja liefert, und dem eigentlichen Soundinterface, an dem unsere Lautsprecher oder Kopfhörer angeschlossen sind, herzustellen. Und genau da setzt ASIO an.

ASIO ist ein Treibermodell, was einen direkten und somit unter Umgehung der systemspezifischen Sound-APIs Zugriff auf die Audiohardware ermöglicht. Wir sparen uns also damit Umwege und somit auch Zeit. Voraussetzung ist allerdings, das der Hersteller des entsprechenden Soundinterfaces entsprechende ASIO-Treiber zur Verfügung stellt. Das ist leider bei onboard-Soundkarten oder anderen, „billigen“ Soundkarten für den PC selten bis nie der Fall. Im ProAudio-Bereich, also dem professionellen Bereich, wo Audio produziert wird wie bei Musikproduktionen, werden wir schnell fündig. Bekannte Hersteller wie YAMAHA, ARTURIA, Native Instruments oder Focusrite, um nur einige zu nennen, haben alle solche Soundinterfaces auf dem Markt und liefern auch mit 95%er Wahrscheinlichkeit entsprechende ASIO-Treiber mit.

Hier mal einfach zwei Interfaces als Beispiel, die unseren Ansprüchen bzgl. ASIO entsprechen würden und die ich bereits mit Thetis erfolgreich im Einsatz habe. Natürlich ist die Auswahl viel, viel größer. Gut oder schlecht gibt es im ProAudio-Bereich eher selten, im Grunde funktionieren sie alle gut bis sehr gut.

Um nun unter Thetis cmASIO zu aktivieren, ist leider ein Eingriff in die Registry erforderlich, denn cmASIO lässt sich bis heute nicht direkt im Thetis-Setup einstellen:

Unter HKLM\SOFTWARE\OpenHPSDR\Thetis-x64 ist ein Schlüssel vom Typ REG_SZ mit der Bezeichnung „ASIOdrivername“ hinzuzufügen, der als Wert die Bezeichnung des jeweiligen ASIO-Treibers enthält. In meinem Falle für das ARTURIA MiniFuse 1 heist dieser „MiniFuse ASIO Driver“. Es gibt auch eine PDF im Programmverzeichnis vom Thetis (normalerweise
C:\Program Files\OpenHPSDR\Thetis) mit dem Namen „cmASIO Guide.pdf“, die könnt Ihr Euch auch gerne noch zusätzlich zu Gemüte führen, da ist es auch nochmals alles erklärt.

Um die entsprechende ASIO-Treiberbezeichnung herauszufinden, schauen wir ebenfalls mal in die Registry:

---

So sähe dann in Falle der Verwendung meines YAMAHA AG03 die Verkablung aus. Das Mic ist per XLR an dem Mic-Eingang angeschlossen, Lautsprecher und Kopfhörer können an diesem Interface getrennt geregelt werden, auch der Mic-Gain wird mittels Gain-Regler und Level-Fader eingestellt. Und das ist auch schon die Besonderheit – sämtliche Regelungen erfolgen direkt am Soundinterface bei ASIO, denn durch die Umgehung der Sound-APIs haben wir nämlich auch keinen Mixer bzw. Laustärkeregelungen per Software. Thetis verbindet sich also direkt und ohne Umwege mit dem ASIO-Treiber des Interfaces. Die beiden VAC, 1 und 2 werden in diesem Falle nicht mehr benötigt, sie können im Thetis deaktiviert werden.

Das ASIO-Treibermodell sieht mehrere Kanäle vor, jeder Input und Output ist also einem eigenen Kanal zugeordnet und wird im Parallelbetrieb übertragen. Meist bringt der ASIO-Treiber der Hardware noch eine Einstellmöglichkeit mit, wo wir die Puffergröße des ASIO-Treibers konfigurieren können.

Rechnet man die Grundlatenz der DSP-Routinen und sonstigem Signalprozessing im Thetis hinzu, was wir weniger in seiner Latenz beeinfussen können, erreichen wir mit ASIO in etwa eine Gesamtlatenz von um die 100ms, was schon mal deutlich weniger als 300-500ms bei Verwendung der Sound-APIs wäre. Bei Extremtests mit noch geringerer Puffergröße erreichten wir fast 50ms, jedoch stößt man dann einfach an technische Grenzen, sprich die Audioübertragung ist dann nicht mehr ausreichend stabil.

Grundsätzlich ist Input 1 des entsprechenden ASIO-Sounddevices dem Mic-Eingang im OpenHPSDR-Thetis bei Verwendung von cmASIO fest zugeordnet. Es gibt keine Möglichkeit, diese Zuordnung derzeit zu ändern.

Weitere Hinweise zu dem Feature cmASIO finden sich in dem Thread https://community.apache-labs.com/viewtopic.php?f=13&t=4923 im User-Forum von Apache Labs USA LLC, den Entwicklern der ANAN-SDR-Transceiver.

Irrtümer

Ich habe immer wieder mal gelesen, das in Bezug auf cmASIO und Thetis Aussagen wie „cmASIO funktioniert nur mit OpenHPSDR Protokollversion 2“ gemacht werden. Seit der Thetis-Version 2.10.3.5 geht es mit beiden Protokollversionen. Ja, es gibt SDR-TRX, die ein eingebautes Soundinterface besitzen und da wohl auch der Audiostream in diese HPSDR-Protokolle reingepackt werden könnte, zumindest bei der HPSDR-Protokollversion 2 ist das wohl der Fall bzw. wurde das vorgesehen und wohl auch so implementiert.

Aber – ASIO ist und bleibt ein Treibermodell mit einem dazugehörenden mehrkanalfähigem Audiotransfer-Protokoll. Wohlgemerkt, Audio – aber nicht I/Q-Data. Es bleibt primär ein Transferprotokoll für Audiodaten in Kombination mit einer Soundhardware. Natürlich könnten SDR-Systeme Soundinterfaces eingebaut haben wie eben schon beschrieben, aber im Normalfall befinden sich sämtliche Audioschnittstellen in der SDR-Software wie Thetis und nirgendwo anders. Da werden also eigentlich auch keine Audiodaten zwischen Thetis und dem SDR transferiert, das sind bereits I/Q-Daten, also Basisbanddaten, die bereits die fertige Modulation enthalten und denen noch eine entsprechende Trägerfrequenz hinzugefügt werden muss (nach der D-A-Wandlung), damit man das als HF-Signal über eine Antenne abstrahlen kann – oder im RX Betrieb das gesamte Spektrum an die SDR-Software zur entsprechenden Demodulation geschickt wird. Pures Audio oder Audiodatenströme kommen da normalerweise nicht unbedingt drin vor.

Kurzum, es funktioniert mit Thetis seit der 2.10.3.5 auch mit dem Hermes Lite 2, welcher nur die OpenHPSDR Protokollversion 1 nutzt, auch mit einem per cmASIO angebundenen Soundinterface – ich habe das ja hier bereits so im praktischen Betrieb im Einsatz.

---

Thetis hat in den Settings von VAC1 und VAC2 ebenfalls die Auswahl des Treibermodells ASIO. Wenn wir von cmASIO reden, ist man allerdings hier an der falschen Stelle, wenn man das, wie im obigen Bild dargestellt, an dieser Stelle vermutet. Warum das da vorhanden ist und zur Auswahl steht – das ist eines der Geheimnisse, die ich in Zusammenhang mit Thetis noch nicht abschließend ergründen und in Erfahrung bringen konnte. Würde man jedenfalls hier per ASIO das Interface anbinden, haben wir wieder die höheren Latenzen wie bei MME, das bringt also mal rein gar nix an dieser Stelle, denn es ist dann wieder VAC1 oder VAC2 samt deren Puffern aktiv und damit auch mit höherer Latenz behaftet. Es ist auch nicht das ASIO-Interface, welches im Thetis als cmASIO (Channel Master ASIO) bezeichnet wird und dem sich dieser Blogbeitrag widmet.

Abschließende Bemerkungen

ASIO ist im Bereich Audio- und Musikproduktion schon lange DER Standard, den dort die eingesetzen Applikationen (DAW – Digitale Audio Workstation) meistens verwenden. Dort gelten ähnliche Rahmenbedingungen wie bei uns mit der SDR-Software, denn heute sind Klangerzeuger wie Synthesizer oder auch Audio-Plugins wie Effekte oder EQ einfach nur noch Software-Plugins, die quasi in Echtzeit das Audio bearbeiten müssen. Wenn also der Musiker auf seinem MIDI-Keyboard eine Taste drückt, darf der Ton nicht erst eine halbe Sekunde später aus dem Lautsprecher kommen. So könnte man nie vernünftig ein Instrument spielen.

Bei uns im Bereich der Funkanwendung mit den SDR ist das speziell bei Sprache/Fonie im Grunde ähnlich gelagert. Dort, wo wir Latenzen senken können, sollten wir es tun. Die Möglichkeit, ASIO zu verwenden, bietet OpenHPSDR-Thetis. Einziger Wermutstropfen – wir brauchen ein entsprechendes Audiointerface, was es leider nicht für 10€ zu kaufen gibt. Etwas mehr muss man schon investieren, meist gehts so ab 100€ erst los. Aber es lohnt sich, denn die Qualität dieser Soundinterfaces ist schon ein anderes Level als das einer 1€-Onboard-Soundkarte wie die häufig anzutreffenden Realtek-Audio-Chips. Auch sind die am Mic-Eingang verwendeten Vorverstärker, die speziell beim Einsatz von dynamischen Mikrofonen erforderlich sind, meist von sehr guter Qualität, was deren oft sehr geringes Rauschmaß angeht. Von einer meist sehr linearen Audio-Signalverarbeitung mal ganz abgesehen. Es muss eben professionellen Ansprüchen genügen und die sind nun mal wesentlich höher als die der einfachen Heimanwender.

Teilweise gibt es sogar in dem Soundinterface eingebaute DSP-Hardware, die u.a. einen EQ oder ein Kompressor gleich im Interface bereitstellen. Im Falle des YAMAHA AG03 ist das nämlich so. Also selbst da könnte man schon vor der SDR-Software den Audio gewissermassen formen. Thetis selbst bietet aber auch genügend Möglichkeiten, das zu tun und das sogar auf einem ziemlich professionellem Level. Aber darauf werde ich in einem späteren Blog-Beitrag nochmals genauer eingehen, denn die TX-Audioaufbereitung im Thetis ist eine sehr komplexe und auch anspruchsvolle Sache, wo man gut wissen sollte, was man wie und warum tut.