Audio delay, crackling, popping

Audio output on some hardware may exhibit noticeable delay, popping, cracking, etc.

To conserve energy, audio is suspended after a short delay when inactive. When waking from suspend, some audio sinks (commonly consumer TVs) can “lag” and send unwanted audio feedback.


Disable audio sleep by adding a drop-in config.

Create the text file ~/.config/wireplumber/main.lua.d/51-disable-suspension.lua with the following:

table.insert(alsa_monitor.rules, {
  matches = {
    {
      { "node.name", "matches", "alsa_input.*" },
    },
    {
      { "node.name", "matches", "alsa_output.*" },
    },
  },
  apply_properties = {
    ["session.suspend-timeout-seconds"] = 0,
  },
})

Then, restart audio:

systemctl restart --now --user pipewire.service pipewire-pulse.service


Additionally, you may experience noticeable delay, popping, cracking, after waking from standby.

This is caused by a known real-time priority bug that manifests between PipeWire and rtkit.

Administrators can disable the real-time canary by editing the systemd service file.


Edit the service file:

sudo systemctl edit --full rtkit-daemon.service

Edit the line starting with ExecStart=, appending the --no-canary flag to the daemon.

Old:

ExecStart=/usr/libexec/rtkit-daemon

New:

ExecStart=/usr/libexec/rtkit-daemon --no-canary

You should see a message such as:

Successfully installed edited file '/etc/systemd/system/rtkit-daemon.service'.

Restart rtkit:

sudo systemctl restart --now rtkit-daemon.service

Check the daemon status with:

systemctl status rtkit-daemon.service

Your output should show something similar to the following:

     CGroup: /system.slice/rtkit-daemon.service
             └─11154 /usr/libexec/rtkit-daemon --no-canary

Sources

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

ArchWiki - PipeWire - Missing realtime priority/crackling under load after suspend

GitHub - heftig/rtkit - Canary thread “starves” after s2idle

License

This work is marked with CC0 1.0

1 Like

Thanks. Common Issues are just about specific issues that need to be highlighted. General problems and how-to guides would make the category explode. I think it’s fine to look for them at Arch Wiki or post them to Fedora Quick Docs. Moving to Ask Fedora .

1 Like

Thanks. I will see if the Docs team would like to highlight this issue.

1 Like

I’m in discussion with jam-team and waiting for docs-team board members about creating how-to guides. You can find a proposal here.

Please make suggestions and take vote. Every opinion counts toward teamwork.

My initial gut reaction to your ideas is repurposing Arch Wiki does not encourage best practice for knowledge creation. The article in Quick Docs has to be unique based on frequently asked questions and solutions provided on Ask Fedora categories about audio and related tags.

Okay,

Found the Fedora Docs repo, opened an issue:

https://pagure.io/fedora-docs/quick-docs/issue/690

I’m confused why you reposted the post to issue ticket in Quick Docs.
To be fair, you quoting article from other forum is plagiarism. Don’t repeat this.

What I suggest to you is to have time to read through a proposal I quoted and see if you can contribute to new articles in selected 10 criteria. I don’t believe your copy and paste post is eligible as a potential article in current form.

Hi, I was encourage to bring up the issue on this thread. Here’s a link:

After reading the Fedora Quick Docs my intuition was to open an issue on Fedora GitLab. My intuition was also to link said issues as it seems quite common and convenient for Fedora contributors to link related issues. My intuition was also that, worse case, the issue would be rejected and closed, no harm done.

I’m sure ArchWiki snippets are under the GNU FDL 1.3 unless otherwise noted.

I’m also sure you are painting, with far too broad a brush, and with far too many strokes, a picture as to what I, as a Fedora member, can and cannot post, and, what I, as a Fedora member, can and cannot repeat.

I’m also sure that you are trying to be helpful. Thanks for that.

1 Like

Hi there,

Some of audio issues on the title of your post was reported and, in part, resolved in many different posts.

Our aim in recent discussion/proposal is to look for consolidating best answers and get them reviewed by a group of experts across various working groups. We started to discuss and waiting for volunteers.

If you experienced audio issues yourself and you had a chance to go through config files in Arch Wiki and it worked on your machine, I understand you must have made valid contributions. Let us know your working and how you picked a specific article in Arch and what additional work you put into it.

“the issue was superfluous and would get harmlessly get closed”.

What do you mean?

My suggestion is to suggest new article topics and report issues with user environment (what external devices and audio settings/versions), suggested wording or technical review. All steps need to be tested by the proposer.

Quick Docs repo is in Pagure (Fedora’s Git forge), not GitLab.

If you are willing to contribute the right way, I’m more than happy to guide and invite you to onboarding video call and workshop.

Assuming the author and source are credited, it’s not “plagiarism” — that’s a strong accusation.

Our docs are generally under CC-BY-SA 4.0. GFDL 1.3 licenses (in several variants) are allowed for Fedora documentation, but appropriate section would need to be labeled properly according to the license. It can be kind of a mess, really (the GDFL has a special relicense-to-CC clause but it was specially tailored for Wikipedia and expired in 2009, so is of no help to us.)

Thinking back, I actually copy-paste-edited the snippet from /usr/share/wireplumber/main.lua.d/50-alsa-config.lua, so the license is whatever the WirePlumber repo uses.

Hello Matt,

Thanks for providing clarity around the nature of accusation.

My intention focuses on what best practice we promote regarding knowledge creation.

I failed to demonstrate the best of empathy and kindness toward other contributors.

However I believe we need to encourage and advocate originality and authenticity of work rather than advocating lax approaches to CC licenses. There are FOSS lawyers by profession, who deal with the growing number of disputes and infringement cases around what is right or not.

Proper attribution takes a bit of efforts. Putting efforts to analyze issues and writing up is even harder than attribution.

I’ll not respond to this thread any further.

2 Likes

Added desktop and removed pulseaudio