Skip to content
GitLab
Closed (duplicated) (duplicated)
Issue created by Isabella Nightshade@xBelladonna

Audio drifts out of sync when using TCP protocol or tunnel sink/source inside a VM

  • PipeWire version (pipewire --version): 0.3.56
  • Distribution and distribution version (PRETTY_NAME from /etc/os-release): Debian GNU/Linux bookworm/sid
  • Desktop Environment: KDE Plasma
  • Kernel version (uname -r): 5.18.0-3-amd64

Description of Problem:

I'm running an interesting setup where I have a host computer with a USB audio interface connected and Proxmox running with some VMs that run music player daemon inside. I'm using pipewire-pulse on the host to provide access to the sound device over the network, using TCP and tunnel sinks. I notice over time that the audio played on the host via MPD via direct TCP inside VMs seem to drift and lag over time, lowering in pitch as the adaptive resampling tries to compensate. I have to restart the stream (which usually involves stopping and restarting the playing song or even the MPD process) to get it to reset. This doesn't seem to happen if I use pulseaudio on the host. This problem also happens if I'm using, for example, pulseaudio on the host and running pipewire-pulse in a VM sending audio to a remote sink on the host. I do this with a VM I use as a kind of desktop PC and it's unusable especially when watching videos. I'm currently working around this by using a USB audio interface plugged directly into the VM via PCI passthrough, and it seems to work fine.

This may be due to how pipewire implements scheduling, as I understand pulseaudio automatically uses IRQ-based scheduling instead of timer-based when it detects it's inside a VM, and the universe inside the VM lagging doesn't affect the sound output on the host.

How Reproducible:

Steps to Reproduce:

  1. Run pipewire-pulse on the hypervisor, or inside the VM, or on both
  2. Set up a tunnel sink from inside the VM to the hypervisor
  3. Play a continuous stream of sound for a long time

Actual Results:

The sound played back on the hypervisor slowly drifts out of sync with the source, slows down, and lowers in pitch.

Expected Results:

The sound played back on the hypervisor should play back in realtime as the VM is feeding the tunnel sink.

Additional Info (as attachments):