Wireplumber .conf properties not applied to a node

Zoomer88 · 2025-07-16 15:32:54

Hello everyone! I'm trying to troubleshoot the borked spdif out on my Creative X-Fi Titanium HD. It has problems outputting compressed 5.1 ac3 streams out of the box. At the same time a USB card Asus Xonar U7 mkII does that just fine.

I have a 'default' configuration of pipewire and wireplumber which is installed with KDE Plasma. No alterations are made except for the /etc/wireplumber/wireplumber.conf.d/51-disable-suspension.conf, where I disabled session.suspend-timeout on all alsa and bluez sources and sinks.

The problem is that stereo LPCM is fine, however any other profile with live compression or a ac3/dts stream from mpv seems to get corrupted in a sense that when it is sent, everything's fine from the system side (no errors), but the receiver (in this case Logitech Z5500) gets confused and either gets stuck in Digital Stereo, No Digital Data, or (in case of running dcaenc and physically plugging-unplugging optical cable a couple of times) recognizes the stream (DTS yada yada), however remains silent and then goes back to Stereo (and still silent). It also glitches a bit when the stream is sent (slow to respond, the display jumps back and forth), so this leads me to believe that the stream is there, however it's malformed.

The aforementioned USB Xonar U7 mkII works fine. Gets out ac3 bit streamed content properly and also works flawlessly with 'Digital Surround 5.1 (IEC958/AC3) Output' profile.

The most important thing for me is not the bitstream from video players, but this Digital Surround profile.

I tried comparing the two sinks using wpctl inspect, and the only difference between them (apart from names/paths) seems to be in the following:
X-Fi:
api.alsa.period-num = "21"
api.alsa.period-size = "768"
node.max-latency = "8064/48000"

USB Xonar:
api.alsa.period-num = "43"
api.alsa.period-size = "768"
node.max-latency = "16512/48000"

According to the Wireplumber daemon configuration manuals, api.alsa.period-num and api.alsa.period-size are configurable. So I created the /etc/wireplumber/wireplumber.conf.d/52-xfi-periods.conf with the following:

monitor.alsa.rules = [
  {
    matches = [
      {
        node.name = "alsa_output.pci-0000_72_00.0.*"
      }
    ]
    actions = {
      update-props = {
        api.alsa.period-num = 43
        api.alsa.period-size = 768
      }
    }
  }
]

But those don't seem to get applied even after a full reboot. No complaints or errors about this config file in the boot log. However, wpctl says that everything's stayed the same, no changes to those props

I'm a total noob, could someone more knowledgeable help me with applying those props?

Maybe the reason those don't get applied is that after the pipewire/wireplumber/pipewire-pulse restart the sink isn't, I don't know, created 'fully'? I.e. there are no api.alsa.period-num and api.alsa.period-size until something sends a sound to this sink. If so, what am I to do in this case?

Also, ist it alright to configure the sink directly through Pipewire? And how one would do that properly? I still can't fully wrap my head around pipewire-wireplumber-pulseaudio trio.

Here is the full wpctl inspect output from Creative X-Fi Titanium HD:

id 47, type PipeWire:Interface:Node
    alsa.class = "generic"
    alsa.device = "0"
    alsa.id = "a52:0"
    alsa.name = "a52:0"
    alsa.resolution_bits = "32"
    alsa.subclass = "generic-mix"
    alsa.subdevice = "0"
    alsa.subdevice_name = "a52:0"
    alsa.sync.id = "00000000:00000000:00000000:00000000"
    api.alsa.card.longname = "Creative X-Fi 20K2 SB1270"
    api.alsa.card.name = "Creative X-Fi"
    api.alsa.headroom = "0"
    api.alsa.path = "a52:0"
    api.alsa.pcm.card = "0"
    api.alsa.pcm.stream = "playback"
    api.alsa.period-num = "21"
    api.alsa.period-size = "768"
    audio.channels = "6"
    audio.position = "FL,FR,RL,RR,FC,LFE"
    card.profile.device = "15"
  * client.id = "48"
    clock.quantum-limit = "8192"
    device.api = "alsa"
    device.class = "sound"
    device.icon-name = "audio-card-analog"
  * device.id = "51"
    device.profile.description = "Digital Surround 5.1 (IEC958/AC3)"
    device.profile.name = "iec958-ac3-surround-51"
    device.routes = "0"
  * factory.id = "19"
    factory.name = "api.alsa.pcm.sink"
    library.name = "audioconvert/libspa-audioconvert"
  * media.class = "Audio/Sink"
  * node.description = "EMU20k2 [Sound Blaster X-Fi Titanium Series] (SB1270 [SoundBlaster X-Fi Titanium HD]) Digital Surround 5.1 (IEC958/AC3)"
    node.driver = "true"
    node.loop.name = "data-loop.0"
    node.max-latency = "8064/48000"
  * node.name = "alsa_output.pci-0000_72_00.0.iec958-ac3-surround-51"
  * node.nick = "a52 0"
    node.pause-on-idle = "false"
  * object.path = "alsa:acp:XFi:15:playback"
  * object.serial = "64"
    port.group = "playback"
  * priority.driver = "1008"
  * priority.session = "1008"
    session.suspend-timeout-seconds = "0"

And here's the one from USB Asus Xonar:

id 35, type PipeWire:Interface:Node
    alsa.class = "generic"
    alsa.device = "0"
    alsa.id = "a52:1"
    alsa.name = "a52:1"
    alsa.resolution_bits = "32"
    alsa.subclass = "generic-mix"
    alsa.subdevice = "0"
    alsa.subdevice_name = "a52:1"
    alsa.sync.id = "00000000:00000000:00000000:00000000"
    api.alsa.card.longname = "ASUS Xonar U7 MKII at usb-0000:00:14.0-3, high speed"
    api.alsa.card.name = "Xonar U7 MKII"
    api.alsa.headroom = "0"
    api.alsa.path = "a52:1"
    api.alsa.pcm.card = "1"
    api.alsa.pcm.stream = "playback"
    api.alsa.period-num = "43"
    api.alsa.period-size = "768"
    audio.channels = "6"
    audio.position = "FL,FR,RL,RR,FC,LFE"
    card.profile.device = "13"
  * client.id = "48"
    clock.quantum-limit = "8192"
    device.api = "alsa"
    device.class = "sound"
    device.icon-name = "audio-card-analog"
  * device.id = "50"
    device.profile.description = "Digital Surround 5.1 (IEC958/AC3)"
    device.profile.name = "iec958-ac3-surround-51"
    device.routes = "0"
  * factory.id = "19"
    factory.name = "api.alsa.pcm.sink"
    library.name = "audioconvert/libspa-audioconvert"
  * media.class = "Audio/Sink"
  * node.description = "Xonar U7 MKII Digital Surround 5.1 (IEC958/AC3)"
    node.driver = "true"
    node.loop.name = "data-loop.0"
    node.max-latency = "16512/48000"
  * node.name = "alsa_output.usb-ASUS_Xonar_U7_MKII-00.iec958-ac3-surround-51"
  * node.nick = "a52 1"
    node.pause-on-idle = "false"
  * object.path = "alsa:acp:MKII:13:playback"
  * object.serial = "166"
    port.group = "playback"
  * priority.driver = "1008"
  * priority.session = "1008"
    session.suspend-timeout-seconds = "0"

And also here's my node suspension disabling file just in case.

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
      }
    }
  }
]

Thanks in advance!

Edit: oh, and I forgot to mention that the cable/hardware is definitely fine. I have a dualboot Windows 11, where Dolby Digital Live encoder, DTS Interactive encoder and bitstream out are all working fine.

Last edited by Zoomer88 (2025-07-16 15:37:01)

V1del · 2025-07-20 21:44:34

Your config option that does not get applied lacks the "~" prefix which would try to match the string as a regex and instead tries to do an exact match.

The correct line would be

node.name = "~alsa_output.pci-0000_72_00.0.*"

Zoomer88 · 2025-07-21 10:06:58

Thank you so much for looking into that! Yeah, it seems, I brainfarted a little with the regex symbol. So I put it in there. Unfortunately, the settings still don't apply.

I also tried to do the exact match by the node's name (alsa_output.pci-0000_72_00.0.iec958-ac3-surround-51) - still no go. period-num always stays at 21.

It got me thinking - maybe it's the type of the device that doesn't not allow to increase period-num or something like that? Then it probably should be in the log. However, I don't see anything regarding incompatible settings there.

I've tried enabling the 3 log level messages (so Info). Unfortunately, there seem to be nothing regarding how these settings are applied to the node (successful or not). The only thing I was able to find is that wireplumber is

opening fragment file: /etc/wireplumber/wireplumber.conf.d/52-xfi-periods.conf

during the initialization stage. Nothing else.

I also tried clearing the configuration cache in ~/.local/state/wireplumber/ as per your post here, V1del. Still no go. How else I can troubleshoot that further? I remember reading somewthere something about system (or device?) timers or somesuch - akin to IRQ. Can't seem to find this info right off the bat. Would it be (is it still) relevant here?

I'm also attaching the level 3 bootlog filtered by wireplumber unit, that I recorded after rebooting with the user config cache cleared. The match is set via regex as per your recommendation. At the very end I'm reconfiguring the nodes to 5.1 config since after the reboot they were at their default stereo profiles.

wireplumber bootlog

Edit: forgot to mention, that I haven't been restarting the pipewire/wireplumber from the terminal. I always opted in for a complete reboot, because, I think, restarting the daemons isn't getting the system back into the fully working state in my case. I think, ac3 encoder craps out or something like that. Haven't yet troubleshot that.

Last edited by Zoomer88 (2025-07-21 10:14:34)

Zoomer88 · 2025-07-21 11:46:52

Mucking around further, I found out that some other properties from the api.alsa family are indeed applied. For example, I had no problem applying api.alsa.headroom value (e.g. 1024) - which doesn't help btw.

It's only with the api.alsa.period-num I have problems. Seems that it gets pulled from somewhere else, some rules - and gets overriden?

Edit: even after some more digging, I found out that indeed the 'wrong' settings get silently discarded somewhere along the way. I was trying to apply api.alsa.period-num of 43 and api.alsa.period-size of 768 I lifted from the usb card - to my pcie x-fi soundcard. This probably was the bad idea because of the said 'batch mode' for usb audio cards, which calculates the buffer size differently.

So I started experimenting and noticed that something gets accepted, while something don't. For example, 1536 (768x2) was accepted for period-size, however period-num also was set to 1536 (?), while I asked for 4. What's more, after changing the node profile and then switching back to ac3 one, period-num is 4 now, and period-size is 768. I'm not exactly sure what's happening there. But it all definitely seems weird.

Last edited by Zoomer88 (2025-07-21 14:26:40)

Arch Linux

#1 2025-07-16 15:32:54

Wireplumber .conf properties not applied to a node

#2 2025-07-20 21:44:34

Re: Wireplumber .conf properties not applied to a node

#3 2025-07-21 10:06:58

Re: Wireplumber .conf properties not applied to a node

#4 2025-07-21 11:46:52

Re: Wireplumber .conf properties not applied to a node

Board footer