Sound crackling / time too fast

Hello,

I have a problem with audio playback in EndeavourOS. My hardware setup is a bit complicated and I will get to that later, but first let me describe the issue and how I found it:

I’ve been using it for a while with no audio (no speakers attached) but recently I wanted to play an old Steam (retro) game, and attached headphones to my screen. I discovered that:

  • there was a LOT of crackling in the audio
  • the problem seemed to get worse as time passed by
  • the audio seemed to “speed up” over time (as if I was playing back at a higher speed)

I stopped the game and opened Firefox to watch a Youtube video. The crackling was there just like in the game. As time went buy I started noticing that the seconds marker on the video seemed weird (as if it skipped one second faster than another). I then performed the following experiment:

I opened a terminal and ran while [ "1" ]; do date ; sleep 1 ; done then started a YouTube video at the 00 second mark synchronized with the terminal output. I saw that time on the TYoutube video was indeed advancing a bit faster than on the terminal. For example, suppose I started the video at 16:34:00, and waited. When the video reached the 1 minute marker, the time on the terminal was only 16:34:47 indicating the video had advanced 13 seconds faster than it should have.

So I think the two are related, likely some time-issue on my system?

Here’s where things get a bit complicated: I use Proxmox to run VMs on my machine and my “desktop VM” is simply one of those VMs. I use GPU-passthrough to attach a Radeon RX6800 to the desktop VM directly, so my performance is amazing. I have no issues using my desktop VM for development and it is snappy and fast. Here are the basic specs of my system:

  • Ryzen 5950X with 16c/32t
  • 64GB for RAM
  • 1xRadeon RX6800 (passed through to the EndeavourOS VM)
  • 1xRadeon RX6700XT (passed through to a Windows 10 VM)

The host system is on Proxmox 7.2 running a 5.15 kernel. EndeavourOS is on the 5.18 kernel.

Now , the reason why I think this is an EndeavourOS issue is that:

  1. The Windows VM using the RX6700XT works fine, including its audio
  2. The RX6800 is being passed through and I am using its audio which means the EndeavourOS kernel has full control of it.
  3. If I run an Ubuntu 22.04 LTS virtual machine instead of my regular EndeavourOS one, the audio on that is fine (I can watch youtube, there is no crackling and the time is advancing properly). This via the same RX6800 that is attached to the EndeavourOS VM.

I’m a bit at a loss on what to do. Not familiar with audio systems at all. I know that recently distros have started using something called pipewire which is supposedly better in latency, but that’s about it…

Some questions:

A) What is different in the audio system of Ubuntu 22.04 versus EndeavourOS? Are they using the same audio stack?

B) What can I do to further investigate (or ideally fix) this?

I am currently installing Fedora 36 to see if it has the same as EndeavourOS, or if it runs fine as Ubuntu/Windows seem to run and will report back.

Please do report back, and also consider this post.

You have a complex “system” that runs everything in VMs? PEBCAK.

2 Likes

You mean @pebcak ?

1 Like

Hello @ivanhoe

I think the problem could be issue Distorted/fast audio inside a VM (QEMU/KVM).

It was opened 5 days ago and the fix was cherry-picked in master.

The wireplumber I use was indeed installed 4 days ago:

$ yay -Qi wireplumber
Name            : wireplumber
Version         : 0.4.11-2
Description     : Session / policy manager implementation for PipeWire
Architecture    : x86_64
URL             : https://pipewire.pages.freedesktop.org/wireplumber/
Licenses        : MIT
Groups          : None
Provides        : pipewire-session-manager  libwireplumber-0.4.so=0-64
Depends On      : pipewire>=0.3.52  lua  libpipewire-0.3.so=0-64  libsystemd.so=0-64
                  libglib-2.0.so=0-64  libgmodule-2.0.so=0-64  libgobject-2.0.so=0-64
                  libgio-2.0.so=0-64
Optional Deps   : wireplumber-docs: Documentation
Required By     : gst-plugin-pipewire  pipewire-alsa  pipewire-jack  pipewire-pulse
Optional For    : pipewire
Conflicts With  : pipewire-media-session
Replaces        : None
Installed Size  : 2.15 MiB
Packager        : Christian Hesse <eworm@archlinux.org>
Build Date      : Tue 12 Jul 2022 13:48:31 BST
Install Date    : Wed 13 Jul 2022 00:16:21 BST
Install Reason  : Installed as a dependency for another package
Install Script  : Yes
Validated By    : Signature

Do you know when the new master version will be released (which contains the cherry-picked fix)?

How can I downgrade wireplumber to the previous version to see if the problem goes away?

EDIT: From my /var/log/pacman.log it looks like this is the update that broke my system:

[2022-07-13T00:16:18+0100] [PACMAN] synchronizing package lists
[2022-07-13T00:16:21+0100] [ALPM] transaction started
[2022-07-13T00:16:21+0100] [ALPM] upgraded alsa-card-profiles (1:0.3.54-1 -> 1:0.3.55-2)
[2022-07-13T00:16:21+0100] [ALPM] upgraded alsa-ucm-conf (1.2.7.1-1 -> 1.2.7.2-1)
[2022-07-13T00:16:21+0100] [ALPM] upgraded alsa-lib (1.2.7.1-1 -> 1.2.7.2-1)
[2022-07-13T00:16:21+0100] [ALPM] upgraded duktape (2.7.0-2 -> 2.7.0-4)
[2022-07-13T00:16:21+0100] [ALPM] upgraded pipewire (1:0.3.54-1 -> 1:0.3.55-2)
[2022-07-13T00:16:21+0100] [ALPM] upgraded wireplumber (0.4.11-1 -> 0.4.11-2)
[2022-07-13T00:16:21+0100] [ALPM] upgraded pipewire-jack (1:0.3.54-1 -> 1:0.3.55-2)
[2022-07-13T00:16:21+0100] [ALPM] upgraded fluidsynth (2.2.7-1 -> 2.2.8-1)
[2022-07-13T00:16:21+0100] [ALPM] upgraded git (2.37.0-1 -> 2.37.1-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded gnome-desktop-common (1:42.2-1 -> 1:42.3-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded gnome-desktop (1:42.2-1 -> 1:42.3-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded gnome-desktop-4 (1:42.2-1 -> 1:42.3-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded gst-plugin-pipewire (1:0.3.54-1 -> 1:0.3.55-2)
[2022-07-13T00:16:22+0100] [ALPM] upgraded imlib2 (1.9.0-3 -> 1.9.1-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded lib32-alsa-lib (1.2.7.1-1 -> 1.2.7.2-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded lib32-libidn2 (2.3.2-1 -> 2.3.3-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded libgit2 (1:1.4.3-1 -> 1:1.4.4-1)
[2022-07-13T00:16:22+0100] [ALPM] upgraded pipewire-alsa (1:0.3.54-1 -> 1:0.3.55-2)
[2022-07-13T00:16:22+0100] [ALPM] upgraded pipewire-pulse (1:0.3.54-1 -> 1:0.3.55-2)
...

As is said in that post, various possibilities may arise (with one million sets of hardware-arrangements encased in plastic).

Did you try them out? If you did already (which seems doubtful) you could still revert to the

Arch Wiki on downgrading packages.

Not sure what you mean, I had a look at that and my system is already on pipewire.

  • wireplumber is installed and pipewire-media-session is missing
  • inxi -Aa gives:
  Sound Server-1: ALSA v: k5.18.12-arch1-1 running: yes
  Sound Server-2: PulseAudio v: 16.1 running: no
  Sound Server-3: PipeWire v: 0.3.55 running: yes
  • running pactl info gives:
Server Name: PulseAudio (on PipeWire 0.3.55)
Server Version: 15.0.0

I also have the JACK support installed:

$ yay -Qq | grep pipe
gst-plugin-pipewire
libpipeline
pipewire
pipewire-alsa
pipewire-jack
pipewire-pulse

I am not sure what you are suggesting I try from that page. It seems my system is already running the latest recommended audio stack. Are you saying I should try moving it back to pulse-audio?

Wireplumber or pipewire-media-session is either/or.
One can try both ways to see and find out what’s happening on their computer.

Pulse-audio can be tried in the case the “either/or” from above (i.e. pipewire audio-system) doesn’t work.

My 2 cents.

:v:

Ok I’ve switched to PulseAudio and so far so good:

$ inxi -Aa
Audio:
  Device-1: Intel 82801I HD Audio vendor: Red Hat QEMU Virtual Machine
    driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:293e
    class-ID: 0403
  Device-2: AMD Navi 21/23 HDMI/DP Audio driver: snd_hda_intel v: kernel
    pcie: gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 1002:ab28
    class-ID: 0403
  Sound Server-1: ALSA v: k5.18.12-arch1-1 running: yes
  Sound Server-2: PulseAudio v: 16.1 running: yes
  Sound Server-3: PipeWire v: 0.3.55 running: yes

Video has been playing for 5 minutes. Usually the problem appears in less than 1 minute.

Interestingly, I noticed this in the service’s log from systemctl --user status pulseaudio:

Jul 17 23:47:06 ironyman pulseaudio[1521]: Disabling timer-based scheduling because running inside a VM.

Looks like I need to stick with pulseauidio until wireplumber is updated again to fix the Distorted/fast audio inside a VM (QEMU/KVM)

Glad you found a fix!

I switched back to pipewire and pipewire-media-session instead of wireplumber and the problem again is fixed.

Looks like the issue only exists with the latest wireplumber specifically.

I think I will try to get that bug reopened. It is unclear to me how the fix is not in eos, since I am using 0.4.11-2 which the bug report says has this fixed…

I didn’t notice your post before. Not sure what you mean, or you have quotes around system. By system I simply meant my computer.

It’s not too complicated. Anyone can install Proxmox and quickly learn it. And many people use QEMU/KVM without even realizing (e.g. via Boxes).

Either way, the problem was indeed a bug introduced with wireplumber/pipewire. Today’s release fixes it so I just wanted to close this thread and report that the bug is fixed and you can use wireplumber, as long as you update to pipewire 0.3.56 which has the VM fix.

…while in the OP:

Just pointing out where @c00ter might have gotten the idea that it might be complicated… :laughing:

Well, you quoted me exactly right: it is A BIT complicated, nut NOT TOO complicated.

The only problem with VMs is that sometimes issues are on the host side, not the VM side, or vice-versa. Step one in troubleshooting is to determine whether something is broken on the host, or inside the VM. Usually the best way to do that is to use another VM guest (as I did with Ubuntu/Fedora/Windows) to see if the problem goes away.

90% of the time though, there is not much difference to running within a VM. I’ve been doing this for over a year now and the only complication was the GPU-passthrough part (which you need to get decent GPU performance), but once you pass that hurdle everything is smooth flying. And the VM acts like a physical host (you can even play games with no issues) in terms of responsiveness.

In fact, in recent kernels (5.15 and later) which have simple-framebuffer and newer amdgpu drivers, you don’t even need to fight with vfio and kernel boot parameters to achieve GPU isolation: it just works (the kernel drivers now know how to release the GPU for use in the VM when vfio requests it).

I would never go back to a pure system now. I have 2 desktops in one (with the two GPUs installed) and can fire up and test a new distro at will without touching my main EOS install. I can also mess with EOS without caring. I have set up BTRFS and snapper to play with but have never been worried because my main system is actually on ZFS which Proxmox takes snapshots/backups of. When I was switching between pulse/pipewire and wireplumber/puilse-session-manager, the first thing I did was grab a snapshot of the VM so that I can go back to original state whenever I choose to do so.

I learned Proxmox because I set up a home lab with pfsense, truenas, docker+apps, etc. Once I was comfortable with it and found out that you can use it for your main machine as well, I immediately switched my desktop and never looked back.

And again, while it is A BIT complicated, it is NOT TOO complicated! :slight_smile:

People should not be driven away from such setups. They have a lot of advantages AND you learn a lot about virtualization/containers.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.