VirtualBox Intel HD Audio and PipeWire Incompatibility / Audio broken after increasing ram to 5 GB / No sound after latest updates - PipeWire Bug?

VirtualBox
21

PulseAudio + Intel HD Audio + Debian = works

Pipewire + Arch Linux + Intel HD Audio = works

Pipewire + Debian + Intel HD Audio = Doesn’t work

OpenSUSE (Tumbleweed) Distro Preview
22
23

Debian bug report:
Debian 12 in VirtualBox with Intel HD Audio, PipeWire, and 4 GB RAM causes videos to fail loading

1 Like
24

Can reproduce using a Debian 13 XFCE VM (not Whonix), using pipewire and pipewire-pulse inside VirtualBox with the audio device set to Intel HD Audio. Ubuntu 24.04 is using Pipewire by default so I wonder if this can be reproduced there. (The AC97 fix worked here as well, and in fact VirtualBox has AC97 as the default audio device for Debian VMs so I didn’t initially notice the problem.)

1 Like
port from pulseaudio to pipewire for audio support
25

It is reproducible on ubuntu. its debian based/upstream design issue.

26

Yep, just confirmed that it happens on Ubuntu too. (Sometimes Ubuntu’s packages are different than Debian’s so it was worth a shot.) So I guess time to see what Arch is doing differently since @Patrick couldn’t reproduce it there.

1 Like
27

So, odd thing, When Pipewire is the only audio server that runs in a session, audio is broken as has been seen. However, you can actually get Pipewire working using the following weird trick:

  • Start audio in Tor Browser, wait for it to hang
  • Pause the audio
  • sudo apt install pulseaudio
  • systemctl --user disable pipewire-pulse.socket
  • systemctl --user disable pipewire-pulse
  • systemctl --user disable pipewire.socket
  • systemctl --user disable pipewire
  • systemctl --user stop pipewire-pulse
  • systemctl --user stop pipewire
  • systemctl --user start pulseaudio
  • Start audio, hear it play
  • Stop audio again
  • systemctl --user disable pulseaudio.socket
  • systemctl --user disable pulseaudio
  • systemctl --user stop pulseaudio
  • systemctl --user start pipewire
  • systemctl --user start pipewire-pulse
  • Start audio, it will actually play through Pipewire now!

If you install qpwgraph, you can see that Pipewire is indeed being used for audio now. I haven’t tested it for an extended period of time but it seems to be stable at least to begin with.

Perhaps Pipewire is doing something related to initialization wrong? It seems like Pulseaudio is able to initialize the audio somehow and then things work with Pipewire thereafter.

1 Like
28

That is really weird indeed.

Minor: It was @nurmagoz who reported that.

29

It looks like this is a known problem upstream and may be fixable with a configuration setting. See No Sound in VMware Fusion or VirtualBox VM's with Fedora 34 Gnome/KDE (#1301) · Issues · PipeWire / pipewire · GitLab, going to test now. EDIT: tried adjusting some of the settings mentioned there, issue did not resolve.

2 Likes
30

hmm i can confirm with vbox 7.1.4 produces the issue for all distros with pipewire i tried arch, fedora… same thing.

so if its upstream from pipewire then we have a ticket already there but dead no reply, if its an vbox or kernel thing/issue then yeah thats gonna be tough to figure where the real issue is.

1 Like
31

When VirtualBox is configured to use Intel HD Audio:

In a Debian 12 virtual machine using PulseAudio, audio works normally. Running systemctl --user status pulseaudio shows the message:

Disabling timer-based scheduling because running inside a VM

This triggers the fallback to the LPIB read method. The kernel log (dmesg) shows:

snd_hda_intel 0000:00:05.0: Invalid position buffer, using LPIB read method instead

In a Debian 13 virtual machine using PipeWire, there is no sound by default. Any of the following three methods can trigger the “using LPIB read method instead” fallback and restore audio functionality:

Method 1

cat /etc/modprobe.d/intelhda.conf

options snd-hda-intel position_fix=1

Method 2

cat \~/.config/wireplumber/wireplumber.conf.d/vbox+hda.conf

monitor.alsa.rules = \[

{
matches = \[
{
node.name = “\~alsa_input.pci.*"
cpu.vm.name = "\~.*”
}
{
node.name = “\~alsa_output.pci.*"
cpu.vm.name = "\~.*”
}
\]
actions = {
update-props = {
api.alsa.disable-tsched = true
}
}
}
\]

Method 3

aplay -D sysdefault /usr/share/sounds/alsa/Front_Center.wav

Explanation
Method 1 forces the driver to use the LPIB read method when the driver is loaded.
Method 2 works similarly to PulseAudio. For virtual machines, it disables timer-based scheduling (Disabling timer-based scheduling), which causes the snd_hda_intel driver to fall back to the LPIB read method.
Method 3 manually triggers the snd_hda_intel driver to switch to the LPIB read method.

For Debian 12 systems using PipeWire, the PipeWire/WirePlumber stack is relatively old. Even when using a Lua script (which is required by older WirePlumber versions), Method 2 is still unable to trigger the snd_hda_intel driver to switch to the LPIB read method. As a result, only Method 1 or Method 3 can be used.

3 Likes
32

Could you test this please? @nurmagoz

1 Like
33

This method worked, how to do it in details:

  • Go to WS sysmaint and run:
sudo nano /etc/modprobe.d/intelhda.conf

then add:

options snd-hda-intel position_fix=1

Saved and exit.

  • Regenerate dracut
sudo dracut --force --regenerate-all

then shut it down.

From WS VM settings:

  • Increase the RAMs to 10+ GB
  • Change the Audio Controller from ICH AC97 to Intel HD Audio

Run WS user and then TB and sound is working good.

Note: Didnt test Method 2 and 3.

2 Likes
34
2 Likes