PipeWire Audio Muting/Delay/Cut-off on MSI Laptop (Tiger Lake-H HD Audio Controller)

Support Sound
1

This is in reference to the PipeWire-related audio muting, delay, or cut-off issue reported here

If you are facing the same or a similar problem, here’s the workaround that actually works.

Strangely, this issue only occurs when using the laptop’s internal speakers. When I plug in headphones, the audio plays normally — with no delays, cut-offs, or muting. Logically, one might expect audio delays or cut-offs to be more likely when an external device such as headphones is connected, but surprisingly, that is not the case. Go figure!?!

As I understand, PipeWire is designed to suspend audio streams when no audio is playing in order to save system resources. But in my case, it caused more trouble and headache than it was worth! It’s like trying to save pennies while losing thousands! It just doesn’t make sense!

When a new audio stream starts (e.g. a YouTube video, music player, or system sound), PipeWire has to restart or re-initialize the audio server. This re-initialization introduces a brief hiccup, causing audio delay, cut-off, or momentary muting.

The issue is especially noticeable on MSI laptops with the Tiger Lake-H HD Audio Controller.

This may or may not be a hardware defect. It may simply be how the PipeWire sound server behaves.

I tried every configuration tweak and suggestion available for PipeWire. None worked!!! Even keeping a silent (inaudible) audio loop running in the background failed, because PipeWire only stays fully active if it detects audible sound. But you don’t want to play quiet “dummy audio” that you can still hear while watching a video or listening to music. That ruins the experience!

So the key is:
:heavy_check_mark: The sound must be audible to the system (so PipeWire stays active).
:heavy_check_mark: The sound must be inaudible to you (so it doesn’t interfere with your experience/enjoyment).

I figured, playing a high-frequency tone above the range of human hearing (around 19–20 kHz) works perfectly.

Step 1. Install SoX (if not installed):
sudo pacman -S sox

Step 2. Run this command in the terminal:
nohup play -n synth sine 19000 vol 0.01 repeat - > /dev/null 2>&1 &

This generates a 19 kHz tone at extremely low volume. You won’t hear it, but PipeWire will, keeping the audio system alive at all times.

To auto-start at boot (systemd user service):
Create a service file in ~/.config/systemd/user/ and name it as you want.

Paste the following into your service file:

[Unit]
Description=Keep audio alive (prevent muting/delay)
After=sound.target

[Service]
ExecStart=/usr/bin/play -n synth sine 19000 vol 0.01 repeat -
Restart=always

[Install]
WantedBy=default.target

To reload and enable the service:

systemctl --user daemon-reload
systemctl --user enable <name-of-your-choice>.service
systemctl --user start <name-of-your-choice>.service

I do hope this information helps someone out there avoid the frustration, wasted time, and countless hours of trial and error that I had to go through.

2

Comments on previous topic were mostly about PulseAudio rather than PipeWire and Wireplumber

Wireplumber default configuration suspends a playback node after 5 seconds

ALSA configuration — WirePlumber 0.5.10 documentation
session.suspend-timeout-seconds

This option configures a different suspend timeout on the node. By default this is 5 seconds. For some devices (HiFi amplifiers, for example) it might make sense to set a higher timeout because they might require some time to restart after being idle.

A value of 0 disables suspend for a node and will leave the ALSA device busy. The device can then be manually suspended with pactl suspend-sink|source.

Type: integer

Archwiki - PipeWire - Troubleshooting - Noticeable audio delay or audible pop/crack when starting playback

This is caused by node suspension when inactive.

With wireplumber, create a new file to overwrite the default configuration:

## ~/.config/wireplumber/wireplumber.conf.d/disable-suspension.conf

monitor.alsa.rules = [
  {
    matches = [
      {
        # Matches all sources
        node.name = "~alsa_input.*"
      },
      {
        # Matches all sinks
        node.name = "~alsa_output.*"
      }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0
      }
    }
  }
]
# bluetooth devices
monitor.bluez.rules = [
  {
    matches = [
      {
        # Matches all sources
        node.name = "~bluez_input.*"
      },
      {
        # Matches all sinks
        node.name = "~bluez_output.*"
      }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0
      }
    }
  }
]

Restart pipewire.service and wireplumber.service to apply changes.

 

Some devices implement their own detection of silence and suspension. For them disabling node suspention alone won’t work. It’s possible to work around them by adding a small amount of noise, making it so the output never goes fully silent:

## .../disable-suspension.conf

session.suspend-timeout-seconds = 0, # 0 disables suspend
dither.method = "wannamaker3", # add dither of desired shape 
dither.noise = 2, # add additional bits of noise ...

It may be necessary to play with dither.noise and dither.method parameters to make it so the noise is sufficiently silent and simultaneously loud enough to prevent detection of silence. See PipeWire documentation.

3

I understand your point, and thanks for your input and suggestions. However, what I’m describing applies to both PipeWire and PulseAudio. I’ve tried using both, and the same audio muting, cut-off, and delay issues persisted. Nothing I tried, including your suggestions, resolved the problem. The only thing that works is the workaround: playing a high-frequency tone using nohup play -n synth sine 19000 vol 0.01 repeat - > /dev/null 2>&1 &.

4

A Tiger Lake laptop would have internal digital microphones and would need to use Sound Open Firmware driver (probably snd_sof_pci_intel_tgl ) and ALSA Use Case Manager (alsa-ucm) HiFi Profiles. A bug in the dmic driver or UCM profiles might affect audio playback

System might also have smart amplifiers to drive the internal speakers. If the smart amplifiers were affected by system suspend (maybe resumed with incorrect sample-rate or bit-depth?)
audio playback to speakers would be affected but audio playback from ALC298 codec to headphone jack would not be affected

Please post more information about ALSA hardware devices

sudo alsa-info.sh --upload
5

Is it okay to upload or attach the output file here? I went through all 2,600 lines to check, and everything looks fine to me, so I think it should be safe to share.

6

2,600 lines is too much for forum
post a link to data uploaded to alsa-project
or use an online pastebin