Introduction

I’m making the move from Windows to Linux ahead of the Windows 10 End of Life this October (2025). For someone who has exclusively used Windows for personal computers and only touched Linux for server applications, this does come with a lot of changes I’ll need to get used to.

Having tried to move a few times before without much luck due to lots of unfixable bugs, I decided to try Fedora. I’m a couple of days in and still nowhere near finished getting things set up, but so far Fedora is proving to be the least buggy KDE based distro I have tried.

It isn’t perfect though. I use an S/PDIF digital audio output to feed an audio transmitter, and under Windows this works perfectly fine. Under Fedora however, where PipeWire and WirePlumber are controlling the audio stack, things don’t work quite as well. After approximately 30 seconds of idle time the interface appears to be suspended entirely, meaning it takes about 250-500ms to wake up again when a sound plays. This is unacceptable as it leads to missed notification sounds and lost words at the start of videos with no intro, which is extremely frustrating.

I just wanted to quickly thank Steven Haigh for their blog post regarding this issue which I used as the basis along with various other forum posts and documentation to figure out how to get this to work with the latest versions of WirePlumber, as Steven’s post is for an older configuration format. Thanks for getting me on the right track Steven!

Fixing the issue

It seems the only way to prevent this issue from occurring is to have some kind of audio playing in the background to prevent the interface from going to sleep. Luckily, WirePlumber provides a method of configuring this for PipeWire natively without having to run a process in the background. The sound produced is completely inaudible so won’t disturb you in periods of silence.

Selecting the correct target device

To find the device you want to apply this fix to, start playing some audio. Open a terminal and run pw-top which will give you a list of your audio devices and the applications currently using them. Here is an example where I am playing Spotify out on my S/PDIF interface:

As you can see above, spotify is a child of alsa_output.pci-0000_2d_00.4.iec958-stereo which is the ALSA name for my S/PDIF audio interface. We’ll need this exact name for the configuration we’re going to create.

It’s also useful to note, once you let the interface idle for a moment the list will look like this:

This is useful because we can see the FORMAT column is blank for our device. This column will never go blank once our configuration has been applied, meaning we can use it as an indicator for whether our configuration is working correctly or not.

Creating the configuration

Here is my exact configuration for this fix. I have saved it as /etc/wireplumber/wireplumber.conf.d/51-spdif-keepalive.conf and I recommend you do the same:

monitor.alsa.rules = [
  {
    matches = [
      {
        node.name = "alsa_output.pci-0000_2d_00.4.iec958-stereo"
      }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0,
        node.pause-on-idle = false,
        node.suspend-on-idle = false,
        dither.method = "wannamaker3",
        dither.noise = 2
      }
    }
  }
]

As you can see, I have placed my device name alsa_output.pci-0000_2d_00.4.iec958-stereo into the matches section of the configuration. You’ll need to adjust this value to the name of your own device.

You may find that setting session.suspend-timeout-seconds alone is enough to fix your issue. I’ll leave it to you, the reader, to experiment with which options are required for your particular setup. The above is a blanket configuration which should fit most scenarios.

The configuration should be owned by the user root in group root which if it is not, you can do with chown root:root 51-spdif-keepalive.conf and you can check with the ls -la command.

The configuration will not be applied immediately and you’ll need to restart the WirePlumber service for it to take effect, which you can do by running systemctl --user restart wireplumber or alternatively by rebooting.

Confirming it works

Once applied, the first sound you play will wake your audio interface up. Once woken up, the interface will be kept alive by the configuration we created.

You can see the interface being kept alive by looking at the FORMAT column as shown below, where there are no children to the interface producing sound but a FORMAT is still selected:

Bluetooth too?

If you experience this same issue on a Bluetooth audio device, which you most likely will, you can apply a similar configuration which affects all bluetooth audio devices simultaneously. I created /etc/wireplumber/wireplumber.conf.d/51-bluetooth-keepalive.conf which fixed my issue with my wireless headphones too:

monitor.bluez.rules = [
  {
    matches = [
      {
        node.name = "~bluez_output.*"
      }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0
      }
    }
  }
]

Like with the other configuration, a restart of WirePlumber is required for this to take effect. I needed to disconnect and reconnect my wireless headphones to stop them from behaving strangely after this config change too.