Skip to main content

OBS unter Fedora Linux: Stotternder Mikrofonton mit Focusrite Vocaster und PipeWire

Einleitung

Ich verwende OBS Studio (wie wahrscheinlich so ziemlich jeder auf diesem Planeten) zum Aufnehmen von Spiele Videos, zum Live Streaming auf Twitch und manchmal auch, um mir einfach von dem, was ich gerade so mache, ein Bildschirmvideo mitzuschneiden als "live doku". Im Gegensatz zu vielen anderen mache ich das aber unter Fedora Linux, mit all den kleinen Nickligkeiten, die das so mit sich bringt.

Mein Audioequipment besteht aus einem Focusrite Vocaster One als USB Audiointerface und einem recht einfachen dynamischen Mikrofon, dass per XLR am Audiointerfacce hängt.

Bei Live-Streams mit OBS trat plötzlich ein stark stotternder Mikrofonton auf. Andere Audioquellen, beispielsweise Intro-Musik oder Spielsound, blieben dagegen weitgehend störungsfrei. Ich habe versucht, das Problem weiter einzugrenzen und musste mir dann doch irgendwann Unterstützung von ChatGPT holen, um das Problem vollständig zu analysieren und einen Workaround zu bauen.

Das Problem wirkte zunächst wie eine Folge von:

  • zu hoher Streaming-Bitrate,
  • Encoderüberlastung,
  • Mikrofonfiltern,
  • einem Kernelproblem,
  • einem OBS-Plugin,
  • oder einer PipeWire-Regression.

Da das Problem zunächst erst nach einem Update meines Systems auftrat (zumindest habe ich es danach erst bemerkt), hatte ich sofort einen Treiber Bug oder einen OBS Bug im Verdacht. Zweite Idee war "ich hab da doch gerade ein neues Plugin in OBS installiert".

Durch mehrere kontrollierte A/B-Tests konnte das Fehlerbild mit Hilfe der KI deutlich enger eingegrenzt werden.

Der derzeit stabile Workaround besteht aus:

PipeWire 1.6.5-2
+
direkter Vocaster-Pro-Audio-Eingang
+
Verwendung der ersten beiden Vocaster-Kanäle
(Video Call L/R)
+
keine virtuelle oder remappte Monoquelle

Wichtig: Die eigentliche interne Fehlerursache in OBS beziehungsweise PipeWire ist damit nicht abschließend belegt. Die Messergebnisse sprechen jedoch stark für ein Timing- oder Timestamp-Problem zwischen virtuellen PipeWire-Quellen, pipewire-pulse und dem PulseAudio-Eingangsmodul von OBS.

Umgebung

Betriebssystem und Desktop

Fedora Linux 44
KDE Plasma
Wayland

Hardware

CPU: AMD Ryzen 7 5800X
GPU: AMD Radeon RX 7800 XT
Audiointerface: Focusrite Vocaster One

OBS

OBS Studio 32.1.1
Installation: Fedora-RPM
Audio-Abtastrate: 48 kHz
Streaming-Ziel: Twitch
Video-Bitrate: 6000 kbit/s

Zusätzlich waren unter anderem folgende Erweiterungen installiert:

  • Aitum Vertical Canvas
  • obs-pwvideo
  • weitere Kamera- und Streaming-Plugins

Die Plugins konnten über den OBS-Safe-Mode als primäre Ursache weitgehend ausgeschlossen werden.

Getestete Kernel

Linux 7.0.11
Linux 7.0.12

Ein Wechsel zwischen diesen Kernelversionen führte zu keiner relevanten Änderung des Audiofehlers.

Getestete PipeWire-Versionen

PipeWire 1.6.5-2.fc44
PipeWire 1.6.6-1.fc44
PipeWire 1.6.7-1.fc44

Die installierten PipeWire-Pakete umfassten unter anderem:

pipewire
pipewire-alsa
pipewire-config-raop
pipewire-gstreamer
pipewire-jack-audio-connection-kit
pipewire-jack-audio-connection-kit-libs
pipewire-libs
pipewire-plugin-libcamera
pipewire-pulseaudio
pipewire-utils

Fehlerbild

Das Mikrofon klang während des Streams abgehackt beziehungsweise stotternd. Andere Audioquellen, insbesondere Intro-Musik, waren nicht oder deutlich weniger betroffen.

Das ursprüngliche Fehlerbild war:

Mikrofon:
- kurze Audioaussetzer
- teilweise rhythmisches Stottern
- einzelne Wörter oder Silben wurden unterbrochen
- digitale Stille statt normaler Sprachpausen

Musik und andere OBS-Quellen:
- weitgehend sauber

Das Problem trat zunächst nur beim Streaming auf. Später ließ es sich auch in lokalen OBS-Aufnahmen reproduzieren. Damit konnten Twitch, der Twitch-Ingest und die verfügbare Upload-Bandbreite als alleinige Ursache ausgeschlossen werden.

Auflösung und Twitch-Bitrate

Die Ausgabeauflösung wurde testweise auf weniger als 1080p reduziert. Die konfigurierte Twitch-Bitrate blieb jedoch bei ungefähr 6000 kbit/s.

Eine niedrigere Auflösung reduziert hauptsächlich:

  • Renderinglast,
  • Skalierungsaufwand,
  • Encoderlast.

Sie reduziert bei fest eingestelltem CBR jedoch nicht automatisch die konfigurierte Netzwerkbitrate.

Noch entscheidender war:

Mikrofon und Musik werden in OBS vor der Übertragung in gemeinsame Audiotracks gemischt.

Ein Netzwerkproblem kann normalerweise nicht selektiv nur den Mikrofonanteil innerhalb desselben codierten Audiostreams beschädigen.

Zusätzlich enthielten lokale MKV-Aufnahmen dieselben Mikrofonstörungen. Der Fehler entstand somit bereits vor dem Twitch-Upload.

Vocaster-Kanalstruktur

Der Focusrite Vocaster One stellt im Pro-Audio-Profil mehrere USB-Eingangskanäle bereit.

Die relevante Kanalreihenfolge lautet:

Kanal

Signal

1–2

Video Call L/R

3–4

Show Mix L/R

5

Host Microphone

6

Aux

7–10

Loopback 1 und 2

Das direkte XLR-Mikrofonsignal liegt somit auf Kanal 5.

In PipeWire wird dieser Kanal bei einer nullbasierten AUX-Benennung typischerweise als:

AUX4

angezeigt.

Das OBS den Vocaster als zehnkanaliges Gerät erkannt hat, war daher kein Fehler, sondern entsprach der vorgesehenen Gerätearchitektur.

Verhalten des direkten Vocaster-Eingangs in OBS

OBS öffnete den direkten Pro-Audio-Eingang über sein PulseAudio-Modul:

Audio format: s32le, 48000 Hz, 10 channels
10 channels not supported by OBS, using 2 instead for recording

OBS unterstützt in diesem Capture-Pfad nicht alle zehn Kanäle und verwendete daher nur die ersten beiden Kanäle.

Beim Vocaster sind dies:

Video Call L/R

Die Stimme war darüber hörbar, weil der Video-Call-Mix das Host-Mikrofon enthält.

Technisch wurde damit jedoch nicht der isolierte Host-Mikrofonkanal 5 aufgenommen, sondern ein bereits im Vocaster erzeugter Mix.

Erste ausgeschlossene Ursachen

OBS-Filter

Alle Mikrofonfilter wurden testweise entfernt:

  • Noise Suppression
  • Expander
  • Gate
  • Equalizer
  • Compressor
  • Limiter
  • VST-Plugins

Der Fehler blieb bestehen. Damit waren die Filter nicht die primäre Ursache.

Kernel

Der Fehler trat sowohl mit Kernel 7.0.11 als auch mit Kernel 7.0.12 auf. Ein Kernelwechsel löste das Problem nicht.

Drittanbieter-Plugins

OBS wurde mit folgendem Befehl im Safe Mode gestartet:

obs --safe-mode --verbose --unfiltered_log

Im Safe Mode deaktiviert OBS Drittanbieter-Plugins, Skripte und WebSocket-Erweiterungen.

Das Mikrofonstottern trat weiterhin auf.

Damit konnten insbesondere folgende Komponenten als primäre Ursache weitgehend ausgeschlossen werden:

  • Aitum Vertical Canvas
  • obs-pwvideo
  • weitere Drittanbieter-Plugins

Die eingebauten OBS-Module, beispielsweise linux-pulseaudio.so, bleiben im Safe Mode weiterhin aktiv.

Versuch mit einer nativen OBS-PipeWire-Quelle

Es wurde versucht, das Vocaster beziehungsweise eine virtuelle Quelle über die native OBS-Quelle:

Audioeingabeaufnahme (PipeWire)

einzubinden.

Dabei meldete OBS:

Got format: rate 48000 - channels 0 - format 8
swr_alloc_set_opts failed
creation of resampler failed

Die Quelle lieferte aus Sicht von OBS null Audiokanäle. Der Resampler konnte daher nicht initialisiert werden. Zusätzlich sprang die Geräteauswahl nach dem Schließen des Dialogs wieder auf:

Standard

zurück.

Dieser Capture-Pfad war in der vorhandenen Konstellation daher nicht verwendbar.

Erstellung einer virtuellen Monoquelle

Um ausschließlich den echten Host-Mikrofonkanal aufzunehmen, wurde aus dem Vocaster-Kanal AUX4 eine virtuelle Monoquelle erstellt.

Beispielkonfiguration:

mkdir -p ~/.config/pipewire/pipewire.conf.d

cat > ~/.config/pipewire/pipewire.conf.d/90-vocaster-host-mic.conf <<'EOF'
context.modules = [
    {
        name = libpipewire-module-loopback

        args = {
            node.description = "Vocaster Host Microphone"
            audio.position = [ AUX4 ]

            capture.props = {
                node.name = "capture.vocaster_host_mic"

                target.object = "alsa_input.usb-Focusrite_Vocaster_One_USB_<ID>-00.pro-input-0"

                node.passive = true
                stream.dont-remix = true
            }

            playback.props = {
                node.name = "vocaster_host_mic"
                node.description = "Vocaster Host Microphone"

                media.class = "Audio/Source"
                audio.position = [ MONO ]
            }
        }
    }
]
EOF

Die virtuelle Quelle erschien anschließend als:

vocaster_host_mic

und wurde über eine OBS-PulseAudio-Eingangsquelle eingebunden.

Ergebnis der virtuellen Monoquelle

Die virtuelle Quelle funktionierte grundsätzlich und lieferte das gewünschte isolierte Mikrofonsignal.

In OBS stotterte sie jedoch weiterhin. Im Vergleich zur ursprünglichen Mehrkanalquelle trat der Fehler zunächst deutlich seltener auf. Vollständig verschwunden war er aber nicht. An verschiedenen Stellen wurden in den Aufnahmen harte digitale Nullblöcke gefunden.

Typische Aussetzerlängen waren:

ungefähr 13 bis 35 ms
teilweise ungefähr 75 bis 80 ms
vereinzelt mehr als 100 ms

Diese Bereiche bestanden nicht aus leiser Sprache oder normalen Sprechpausen, sondern aus exakt null gesetzten Samples.

Puffer- und Quantum-Tests

Zur Stabilisierung wurden testweise größere PipeWire-Quantums erzwungen:

pw-metadata -n settings 0 clock.force-quantum 1024

und später:

pw-metadata -n settings 0 clock.force-quantum 2048

Bei 48 kHz entsprechen diese Werte ungefähr:

1024 Samples = 21,3 ms
2048 Samples = 42,7 ms

Die Änderungen verschlechterten das Verhalten.

Der erzwungene Quantum betrifft den gesamten PipeWire-Graph und nicht ausschließlich die Mikrofonquelle.

Die Einstellungen wurden daher wieder zurückgesetzt:

pw-metadata -n settings 0 clock.force-quantum 0
pw-metadata -n settings 0 clock.force-rate 0

Zusätzlich wurden manuell gesetzte node.latency-Werte wieder aus der Loopback-Konfiguration entfernt.

Auffällige OBS-Zeitstempelmeldungen

Im OBS-Terminal beziehungsweise im unfiltrierten Log erschienen wiederholt Meldungen wie:

Audio timestamp for 'Audioeingabeaufnahme (PulseAudio)'
exceeded TS_SMOOTHING_THRESHOLD
diff=74896209 ns

Der Zeitunterschied von ungefähr:

75.000.000 ns

entspricht ungefähr:

75 ms

Dieser Wert entsprach auffällig genau der Länge vieler in den MKV-Dateien gemessener Audioaussetzer.

Das Muster war teilweise:

  1. Ein Audioblock traf ungefähr 75 ms zu spät ein.
  2. Der darauffolgende Block traf nahezu unmittelbar danach ein.
  3. OBS korrigierte beziehungsweise glättete die Zeitstempel.
  4. In der fertigen Aufnahme entstanden digitale Nullbereiche.

Dies deutet auf eine blockweise oder schubweise Anlieferung von Audiodaten hin, mit der die OBS-Zeitstempelbehandlung nicht zuverlässig umgehen konnte.

Direkte Vergleichsaufnahmen außerhalb von OBS

Um zu prüfen, ob das Problem bereits in PipeWire oder pipewire-pulse entstand, wurde dieselbe virtuelle Quelle parallel außerhalb von OBS aufgenommen.

Native PipeWire-Aufnahme

pw-record \
    --target vocaster_host_mic \
    --rate 48000 \
    --channels 1 \
    --channel-map mono \
    /tmp/vocaster-native.wav

PulseAudio-kompatible Aufnahme

parecord \
    --device=vocaster_host_mic \
    --file-format=wav \
    --rate=48000 \
    --channels=1 \
    /tmp/vocaster-pulse.wav

Ergebnis

Beide Dateien waren sauber:

vocaster-native.wav:
- keine internen digitalen Aussetzer

vocaster-pulse.wav:
- keine internen digitalen Aussetzer

Damit funktionierten folgende Signalwege:

Vocaster
→ ALSA
→ PipeWire
→ virtuelle Monoquelle
→ pw-record

und:

Vocaster
→ ALSA
→ PipeWire
→ virtuelle Monoquelle
→ pipewire-pulse
→ parecord

Der Fehler trat jedoch auf, sobald OBS dieselbe Quelle über sein PulseAudio-Eingangsmodul aufnahm.

Kontrollierter A/B-Test innerhalb derselben OBS-Sitzung

Der entscheidende Test erfolgte innerhalb derselben OBS-Sitzung.

Alle Rahmenbedingungen blieben identisch:

  • gleiche OBS-Instanz,
  • gleiche Szene,
  • gleiche Encoderlast,
  • gleiche PipeWire-Version,
  • gleiche Videoquellen,
  • gleiche Audioeinstellungen,
  • gleiche Hardware.

Es wurde ausschließlich die Mikrofonquelle gewechselt.

Test A: Direkter Vocaster-Pro-Eingang

alsa_input.usb-Focusrite_Vocaster_One_USB_<ID>-00.pro-input-0

OBS verwendete daraus Kanal 1 und 2:

Video Call L/R

Ergebnis:

Audio sauber
keine relevanten digitalen Nullblöcke

Test B: Virtuelle Monoquelle

vocaster_host_mic

Ergebnis:

starke hörbare Aussetzer
zahlreiche digitale Nullblöcke
viele Aussetzer im Bereich von ungefähr 75 ms

Dieser Test zeigte eindeutig, dass nicht die allgemeine OBS-, GPU- oder Systemlast das Fehlerbild erzeugt, sondern die verwendete Audioquelle beziehungsweise deren Capture- und Timestamp-Pfad.

Test mit module-remap-source

Als Alternative zur PipeWire-Loopback-Quelle wurde eine PulseAudio-kompatible Remap-Quelle erstellt.

Beispiel:

MASTER='alsa_input.usb-Focusrite_Vocaster_One_USB_<ID>-00.pro-input-0'

pactl load-module module-remap-source \
    source_name=vocaster_host_mic_remap \
    master="$MASTER" \
    master_channel_map=aux4 \
    channels=1 \
    channel_map=mono \
    rate=48000 \
    format=s32le \
    remix=no \
    source_properties='device.description=Vocaster_Host_Microphone_Remap'

Das Stottern war mit dieser Quelle geringer als bei der PipeWire-Loopback-Quelle, aber weiterhin vorhanden. Damit war auch die Remap-Quelle keine vollständig stabile Lösung.

Einfluss der PipeWire-Version

Die PipeWire-Version hatte einen messbaren Einfluss, war aber nicht die einzige Variable.

PipeWire 1.6.6 und 1.6.7

Mit den neueren PipeWire-Versionen trat der Fehler in der normalen OBS-Konfiguration reproduzierbar auf.

PipeWire 1.6.5-2

PipeWire 1.6.5-2 funktionierte mit dem direkten Vocaster-Pro-Audio-Eingang und dem Video-Call-Mix stabil. Die virtuellen oder remappten Monoquellen konnten jedoch auch unter PipeWire 1.6.5 weiterhin stottern.

PipeWire 1.6.6 und 1.6.7 verschärfen oder reproduzieren
das Problem in der getesteten Konfiguration.

Die stabile Funktion hängt zusätzlich stark vom verwendeten
Quellentyp und vom OBS-Capture-Pfad ab.

Wahrscheinliche technische Ursache

Die konkrete interne Ursache wurde nicht abschließend bewiesen. Die Messergebnisse sprechen jedoch stark für eine Interaktion zwischen:

virtuelle oder remappte PipeWire-Quelle
→ pipewire-pulse
→ OBS linux-pulseaudio.so
→ OBS Timestamp-Smoothing
→ digitale Aussetzer im OBS-Audiostream

Dafür sprechen insbesondere:

  1. pw-record der virtuellen Quelle war sauber.
  2. parecord der virtuellen Quelle war sauber.
  3. OBS-Aufnahmen derselben Quelle stotterten.
  4. OBS protokollierte Zeitstempeldifferenzen von ungefähr 75 ms.
  5. Die MKV-Dateien enthielten Nullblöcke mit ungefähr derselben Länge.
  6. Die direkte Vocaster-Quelle funktionierte in derselben OBS-Sitzung.
  7. OBS Safe Mode änderte das Verhalten nicht.
  8. Filter, Kernelwechsel und Twitch Stream waren nicht ursächlich.

Stabiler Workaround

Der derzeit stabilste Aufbau ist:

PipeWire 1.6.5-2
+
Vocaster im Pro-Audio-Profil
+
direkter Vocaster-Pro-Eingang in OBS
+
OBS verwendet Kanal 1/2 = Video Call L/R
+
keine virtuelle oder remappte Mikrofonquelle

OBS-Quelle

In OBS wird eine normale PulseAudio-Eingangsquelle verwendet:

Audioeingabeaufnahme (PulseAudio)

Gerät:

alsa_input.usb-Focusrite_Vocaster_One_USB_<ID>-00.pro-input-0

OBS protokolliert dabei:

Audio format: s32le, 48000 Hz, 10 channels
10 channels not supported by OBS, using 2 instead for recording

Audioeinstellungen

Abtastrate: 48 kHz
Monitoring: Aus
Filter: zunächst keine
Globale Mic/Aux-Geräte: deaktiviert

Es sollte genau eine aktive OBS-Capture-Instanz des Vocaster vorhanden sein. Mehrere Szenen können dieselbe bestehende OBS-Audioquelle referenzieren. Es sollten nicht mehrere getrennte Capture-Quellen für dasselbe Gerät angelegt werden.

Einschränkung des Workarounds

Der Video-Call-Ausgang ist kein isoliertes Rohmikrofonsignal. Er kann abhängig von der Vocaster-Konfiguration weitere Signale enthalten.

Mögliche Folge:

Vocaster Video Call Mix enthält Spiel- oder Systemton
+
OBS nimmt Spiel- oder Systemton separat auf
=
Audio wird doppelt ausgegeben

Daher muss geprüft werden:

  • Welche Signale liegen im Video-Call-Mix?
  • Wird Spielsound zusätzlich über OBS aufgenommen?
  • Ist Loopback-Audio im Vocaster-Mix enthalten?
  • Wird das Signal im Stream doppelt oder mit Phasenversatz wiedergegeben?

Der interne Vocaster-Mix sollte so konfiguriert werden, dass über den Video-Call-Ausgang nur die tatsächlich benötigten Signale ausgegeben werden.

Nacharbeiten

Virtuelle Quellen wieder entfernen

PipeWire-Loopback-Konfiguration deaktivieren

mkdir -p ~/.config/pipewire/pipewire.conf.d-disabled

mv \
    ~/.config/pipewire/pipewire.conf.d/90-vocaster-host-mic.conf \
    ~/.config/pipewire/pipewire.conf.d-disabled/ \
    2>/dev/null

Geladene Remap-Module anzeigen

pactl list short modules | grep -E 'remap-source|vocaster'

Ein geladenes Modul kann über seine Modul-ID entfernt werden:

pactl unload-module <MODUL-ID>

Danach PipeWire und WirePlumber neu starten:

systemctl --user restart pipewire pipewire-pulse wireplumber

OBS anschließend vollständig neu starten.

PipeWire 1.6.5 gegen automatische Updates sperren

Da der stabile Workaround derzeit PipeWire 1.6.5-2 benötigt, können die betreffenden Pakete vorübergehend per DNF-Versionlock gesperrt werden.

sudo dnf versionlock add \
    pipewire \
    pipewire-alsa \
    pipewire-config-raop \
    pipewire-gstreamer \
    pipewire-jack-audio-connection-kit \
    pipewire-jack-audio-connection-kit-libs \
    pipewire-libs \
    pipewire-plugin-libcamera \
    pipewire-pulseaudio \
    pipewire-utils

Kontrolle:

sudo dnf versionlock list

Falls das Versionlock-Plugin fehlt:

sudo dnf install dnf5-plugins

Warnung: Ein Versionlock verhindert auch spätere Fehlerkorrekturen und möglicherweise sicherheitsrelevante Updates. Die Sperre sollte daher regelmäßig überprüft und nach einem bestätigten Fix wieder entfernt werden.

Sperre später entfernen

sudo dnf versionlock delete \
    pipewire \
    pipewire-alsa \
    pipewire-config-raop \
    pipewire-gstreamer \
    pipewire-jack-audio-connection-kit \
    pipewire-jack-audio-connection-kit-libs \
    pipewire-libs \
    pipewire-plugin-libcamera \
    pipewire-pulseaudio \
    pipewire-utils

Danach aktualisieren:

sudo dnf upgrade --refresh \
    pipewire \
    pipewire-alsa \
    pipewire-config-raop \
    pipewire-gstreamer \
    pipewire-jack-audio-connection-kit \
    pipewire-jack-audio-connection-kit-libs \
    pipewire-libs \
    pipewire-plugin-libcamera \
    pipewire-pulseaudio \
    pipewire-utils

Nach einem PipeWire-Versionswechsel sollte das System vollständig neu gestartet werden.

Verwendete Diagnosebefehle

Installierte Versionen anzeigen

rpm -qa \
    --qf '%{NAME}|%{EPOCHNUM}:%{VERSION}-%{RELEASE}|%{ARCH}|%{SOURCERPM}\n' \
    'pipewire*' |
    sort

PipeWire- und PulseAudio-Quellen anzeigen

wpctl status -n
pactl list short sources

PipeWire-Graph überwachen

pw-top

Die Spalte ERR sollte bei allen relevanten Audioknoten auf 0 bleiben.

OBS im Safe Mode starten

obs --safe-mode --verbose --unfiltered_log

OBS-Logs nach Zeitstempelfehlern durchsuchen

grep -Rni \
    'TS_SMOOTHING_THRESHOLD\|Audio timestamp\|Max audio buffering\|audio is lagging' \
    ~/.config/obs-studio/logs

Direkte PipeWire-Testaufnahme

pw-record \
    --target vocaster_host_mic \
    --rate 48000 \
    --channels 1 \
    --channel-map mono \
    /tmp/vocaster-native.wav

PulseAudio-kompatible Testaufnahme

parecord \
    --device=vocaster_host_mic \
    --file-format=wav \
    --rate=48000 \
    --channels=1 \
    /tmp/vocaster-pulse.wav

Bugreport und externe Dokumentation

Die Untersuchung wurde in einem bestehenden OBS-GitHub-Issue dokumentiert.

Relevant sind insbesondere:

OBS Issue #12835
OBS Issue #4600

Der Bericht enthält:

  • OBS-Safe-Mode-Logs,
  • saubere und fehlerhafte MKV-Aufnahmen,
  • saubere pw-record-Aufnahmen,
  • saubere parecord-Aufnahmen,
  • PipeWire-Versionen,
  • Kernelversionen,
  • Kanalbelegung des Vocaster,
  • die virtuelle PipeWire-Konfiguration,
  • und den kontrollierten A/B-Test.

Fazit

Das Problem war kein allgemeiner Mikrofon-, USB-, Kernel-, Twitch- oder Encoderfehler. Der Fehler hing wesentlich vom verwendeten Audio-Capture-Pfad ab.

Sauber funktionierte:

Vocaster Pro Audio
→ direkter 10-Kanal-Eingang
→ OBS PulseAudio
→ Kanal 1/2 Video Call L/R

Fehlerhaft war dagegen:

Vocaster Pro Audio AUX4
→ virtuelle oder remappte Monoquelle
→ pipewire-pulse
→ OBS PulseAudio
→ Timestamp-Smoothing
→ ungefähr 75 ms lange Audioaussetzer

Der derzeitige Workaround ist technisch nicht ideal, aber reproduzierbar stabil:

PipeWire 1.6.5-2
+
direkter Vocaster-Pro-Audio-Eingang
+
Video Call L/R

Eine endgültige Lösung erfordert wahrscheinlich eine Korrektur in OBS, PipeWire oder der Interaktion beider Komponenten bei virtuellen beziehungsweise remappten Audioquellen.

No comments to display

Back to top
Entity Select