Echtzeit-Audioübersetzung unter Windows — ohne Treiber und virtuelle Kabel

Die Idee klingt einfach: Ein Tool, das alles, was auf dem Windows-PC abgespielt wird – sei es ein Video, ein Spiel oder ein Anruf – in Echtzeit übersetzt und die Übersetzung als gesprochenen Text wiedergibt. Doch hinter dieser vermeintlichen Einfachheit stecken technische Herausforderungen, die viele ähnliche Projekte scheitern lassen. Die Open-Source-App Voxis zeigt nun, wie es ohne virtuelle Audiokabel, Treiber oder Bots gelingt.

Was Voxis anders macht

Die meisten Tools für die Audioübersetzung unter Windows setzen auf virtuelle Audiokabel wie VB-CABLE oder VoiceMeeter, die das Systemaudio umleiten. Andere nutzen Bots, die sich in Anrufe einwählen. Voxis hingegen verzichtet komplett auf solche Umwege und erfasst das Systemaudio direkt – und zwar ohne zusätzliche Installation. Doch wie gelingt das?

Drei Kernanforderungen definieren die Lösung

1. Ohne Treiber: Jede Lösung, die einen Treiber oder ein Reboot erfordert, scheidet aus.

1. Kein Echoeffekt: Die App darf ihre eigene Ausgabe nicht mitübersetzen. Das würde zu einer endlosen Schleife aus Übersetzung und Wiedergabe führen.

1. Echtzeitfähigkeit: Die Audioerfassung muss stabil laufen, selbst wenn nachgelagerte Prozesse wie Spracherkennung oder Übersetzung kurzzeitig blockieren.

Die Lösung: WASAPI-Prozess-Loopback

Windows 10 Version 2004 brachte eine entscheidende Funktion mit: ApplicationLoopback. Diese API ermöglicht es, ein IAudioClient-Objekt im Loopback-Modus für einen bestimmten Prozessbaum zu aktivieren – entweder inklusive oder exklusive dieses Baums. Für Voxis ist die exklusive Variante entscheidend: Sie erfasst alles, was der Nutzer hört – ohne die eigene Ausgabe der App.

So aktiviert man den Loopback-Modus

Der Loopback-Client wird nicht über den üblichen IMMDeviceEnumerator angesprochen. Stattdessen nutzt Voxis die Funktion ActivateAudioInterfaceAsync, die mit spezifischen Parametern gefüttert wird. Diese Parameter werden als PROPVARIANT mit einem BLOB übergeben:

params = AUDIOCLIENT_ACTIVATION_PARAMS()
params.ActivationType = AUDIOCLIENT_ACTIVATION_TYPE_PROCESS_LOOPBACK
params.u.ProcessLoopbackParams.TargetProcessId = my_pid
params.u.ProcessLoopbackParams.ProcessLoopbackMode = \
PROCESS_LOOPBACK_MODE_EXCLUDE_TARGET_PROCESS_TREE

pv = PROPVARIANT()
pv.vt = VT_BLOB
pv.blob.cbSize = sizeof(params)
pv.blob.pBlobData = ctypes.cast(byref(params), c_void_p)

Der entscheidende Teil ist der Gerätename `VAD\Process_Loopback`, der die Aktivierung steuert. Diese Funktion ist asynchron: Man übergibt einen Abschluss-Handler und wartet auf dessen Rückmeldung.

Die Falle mit IAgileObject

Ein häufiger Stolperstein bei COM-Objekten in Python ist die fehlende Unterstützung für `IAgileObject`. Der Abschluss-Handler muss nicht nur IActivateAudioInterfaceCompletionHandler implementieren, sondern auch IAgileObject – eine Markerschnittstelle, die angibt, dass das Objekt in jeder Wohnung (Apartment) aufgerufen werden darf.

Ohne diese Schnittstelle scheitert die Aktivierung mit dem Fehler `E_ILLEGAL_METHOD_CALL`, ohne dass eine hilfreiche Fehlermeldung ausgegeben wird. Die Lösung ist simpel:

class _Handler(COMObject):
    _com_interfaces_ = [IActivateAudioInterfaceCompletionHandler, IAgileObject]

IAgileObject selbst enthält keine Methoden – es ist lediglich ein Versprechen, dass das Objekt unabhängig von der Ausführungsumgebung aufgerufen werden kann.

Das perfekte Audioformat direkt abgreifen

Ein weiterer Vorteil von WASAPI: Die Initialisierung des Loopback-Clients erlaubt die Angabe des gewünschten Audioformats. Voxis nutzt dies, um 16 kHz, Mono und 16-Bit-PCM direkt anzufordern – genau das Format, das das Übersetzungssystem benötigt. So entfällt eine nachträgliche Resampling-Schritt im kritischen Pfad:

wfx.nChannels = 1
wfx.nSamplesPerSec = 16000
wfx.wBitsPerSample = 16

client.Initialize(
    AUDCLNT_SHAREMODE_SHARED,
    AUDCLNT_STREAMFLAGS_LOOPBACK,
    2_000_000,  # 200 ms Puffer in 100-ns-Einheiten
    0,
    byref(wfx),
    None
)

Echtzeitfähigkeit durch Thread-Trennung

Die größte Herausforderung bei der Audioerfassung ist die Rechtzeitigkeit. Ein Loopback-Client hat nur eine Aufgabe: den Audio-Puffer abrufen, kopieren und freigeben. Jede Verzögerung führt zu Glitches oder Stottern.

Voxis löst dies durch eine zweithreadige Architektur mit einer begrenzten Warteschlange:

• Erfassungsthread: Holt Pakete ab, kopiert sie in ein numpy-Array und hängt sie an eine collections.deque an. Dieser Thread führt keinerlei weitere Verarbeitung durch.

• Verarbeitungsthread: Liest die Warteschlange aus und führt langsame Operationen wie Spracherkennung oder Übersetzung durch.

Die Warteschlange ist als deque mit begrenzter Länge implementiert (maxlen=64). Falls der Verarbeitungsthread hinterherhinkt, werden ältere Pakete automatisch verworfen – statt den Erfassungsthread zu blockieren. Dies verhindert Pufferüberläufe und hält die Latenz innerhalb akzeptabler Grenzen:

self._queue = collections.deque(maxlen=64)  # Begrenzte Warteschlange (~Puffergröße)

# Erfassungsthread:
self._queue.append(x)  # Blockiert nie; ältestes Element wird bei Druck verworfen

Audio-Ducking ohne Eingriff in die Wiedergabe

Wenn die Übersetzung gesprochen wird, soll das ursprüngliche Audio leiser werden, um Konflikte zu vermeiden. Eine naheliegende Lösung wäre, das Audio in der Pipeline zu mischen und abzudämpfen. Doch dies würde bedeuten, dass Voxis die Wiedergabe und das Routing für alle Systemanwendungen übernehmen müsste – mit zusätzlicher Latenz.

Stattdessen setzt Voxis auf die Windows-Session-Volume-API (ISimpleAudioVolume über pycaw), um die Lautstärke der Audio-Session des ursprünglichen Programms zu reduzieren. Das Original läuft weiterhin über seinen eigenen Pfad, wird aber leiser abgespielt. Sobald die Übersetzung endet, kehrt die Lautstärke auf den ursprünglichen Wert zurück. Dies geschieht ohne zusätzliche Latenz oder komplexe Mischroutinen.

Fazit: Eine saubere Lösung ohne Kompromisse

Voxis beweist, dass eine Echtzeit-Audioübersetzung unter Windows auch ohne virtuelle Kabel oder Treiber möglich ist. Der Schlüssel liegt in der intelligenten Nutzung der WASAPI-Prozess-Loopback, der Trennung von Erfassung und Verarbeitung sowie der cleveren Steuerung der Lautstärke über die Session-API. Die App zeigt, wie moderne Windows-APIs genutzt werden können, um komplexe Audioprobleme elegant zu lösen – ohne den Nutzer mit technischen Hürden zu belasten.

Mit Open-Source-Ansätzen wie diesem wird die Zukunft der Audioverarbeitung unter Windows nicht nur zugänglicher, sondern auch effizienter. Wer selbst experimentieren möchte, findet den Code auf GitHub. Die Technologie ist da – jetzt muss sie nur noch flächendeckend eingesetzt werden.