Usage help

[UltraBlackLinux]

Hey there,
I just found this project, and it solves some issues I've been dealing with for a while, but I just can't for the life of me get this to work.

I tried to follow the sparse documentation as far as possible, but nothing is connecting.

This is my current config:

[general]
linger_links = false
hotreload_config = true

[log]
# trace / debug / info / warn / error
level = "info"

[bluez_card.00_1B_66_E8_CB_52] # I guess this line is where the issue resides. What is the node?
source = "alsa_input.usb-Yamaha_Corporation_Yamaha_MX_Series-00.iec958-stereo"
sink = "bluez_output.00_1B_66_E8_CB_52.1"
special_empty_ports = true

The following are the in- and outputs of the corresponding nodes:

Out:
alsa_input.usb-Yamaha_Corporation_Yamaha_MX_Series-00.iec958-stereo:capture_FL
alsa_input.usb-Yamaha_Corporation_Yamaha_MX_Series-00.iec958-stereo:capture_FR

In:
bluez_output.00_1B_66_E8_CB_52.1:playback_FL
bluez_output.00_1B_66_E8_CB_52.1:playback_FR

What do I need to do? I don't understand.
Thanks!

[Teascade]

This is certainly a good example why it probably would be a good idea to try and match node-names exactly, as well as using regular expressions.

In this particular case I think the issue lies with RegEx syntax. Source/Sink are currently only read as RegEx, so as you've input the whole name of the nodes (including dots) into the sink and source.

I would try if you have any luck using something like this

source = ".*Yamaha_Corporation_Yamaha_MX_Series.*"
sink = ".*bluez_output.*"

You can try to use https://regexr.com/ to preview what kinds of symbols can have special meanings in regex. . is among those, and I think that might be causing the issue here.

Also, special_empty_ports is true by default so you don't need to specify that, if you like :)

[Teascade]

Oh two things new things actually after reading the issue even further;

The issue might not actually be in the RegEx, but actually the header itself should not contain dots. I should probably mention about this in the readme if I can find a source that would definitively declare what symbols you can use for headers, but periods actually have a semantic meaning in TOML that will probably make the config not work as intended. So another thing I would actually try even before my earlier suggestion is to rename the header as simply [link.bluez_card] (the link. is important at the start, links are included as a TOML table)

---

Another thing I realized you had asked;

What is the node?

Another tool you can actually use to preview specifically the nodes/etc. exist within your system aside from pw-link is actually pw-dump. It gives a lot of information you probably don't need, but it gives a more "perfect" preview of what you're actually working with.

[UltraBlackLinux]

I just applied these changes and for some reason it still does not work.

I still think this is related to the node issue. I took a look at pw-dump but I still don't know what to look for. Is the node you are referring to the node.id or the node.name? What is it? The directions are rather unclear to me

[Teascade]

node.name is the one that's being used for regex comparison. What does the config file look like now then?

One configuration that maybe looks a little similar that I have that works fine, looks like this

[link.ps5-to-headset]
source = ".*pci-0000_2d_00.4.*"
sink = ".*Ti_USB_Audio.*"

Apparently it has periods as well, so they might not cause an issue, but you do want to be a little careful about using them in the header at least

[UltraBlackLinux]

Okay, seems like I was a little confused about the toml block name. I thought that was relevant for some detection too.

Anyways, this is still not working. I double-checked all the names and I'm out of ideas:

[link.keybord-to-350bt]
source = ".*Yamaha_Corporation_Yamaha_MX_Series.*"
sink = ".*00_1B_66_E8_CB_52.*"

[Teascade]

That is a little confusing..

One thing you could try is to set the log level to trace and post here what is logged after you restart pipeswitch. Restarting is important here, because the log level is one of the things that aren't updated with hot-reload.

[UltraBlackLinux]

That is a little confusing..

One thing you could try is to set the log level to trace and post here what is logged after you restart pipeswitch. Restarting is important here, because the log level is one of the things that aren't updated with hot-reload.

I already tried that. Unless it's not printed into the service file, nothing but a few probably unrelated errors appeared, which is a little less than what I would expect from the trace output

[Teascade]

Hmm. Are you sure the service is enabled? When I run journalctl --user -eu pipeswitchd.service the logs from the service itself is always something like this:

tammi 16 20:33:51 celebi pipeswitchd[59714]: 2023-01-16T20:33:51+02:00 - DEBUG - rechecking config
tammi 16 20:33:51 celebi pipeswitchd[59714]: 2023-01-16T20:33:51+02:00 - TRACE - re-checking following rules: {"music", "ps5-to-obs", "firefox", "vive", "games"}
tammi 16 20:33:51 celebi pipeswitchd[59714]: 2023-01-16T20:33:51+02:00 - INFO - config updated: 5 new rules
tammi 16 20:33:51 celebi pipeswitchd[59714]: 2023-01-16T20:33:51+02:00 - DEBUG - config checked
.... more logs after this

At least the rechecking config log should always show up regardless of if your config has actually working rules or not.

[UltraBlackLinux]

This is what I'm getting from a sytemctl --user restart pipeswitch:

Jan 16 18:27:47 lolcat systemd[838]: Stopping Pipeswitch Daemon...
Jan 16 18:27:47 lolcat systemd[838]: Stopped Pipeswitch Daemon.
Jan 16 18:27:47 lolcat systemd[838]: Started Pipeswitch Daemon.
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - INFO - config updated: 1 new rules
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - WARN - property 'client.id' not found in object 29 of type PipeWire:Interface:Node: {"node.name": "Dummy-Driver", "pr>
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - WARN - property 'client.id' not found in object 30 of type PipeWire:Interface:Node: {"priority.driver": "19000", "obj>
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 2
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 2
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 3
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 3
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 4
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 4
Jan 16 18:27:47 lolcat pipeswitchd[173892]: 2023-01-16T18:27:47+01:00 - ERROR - direction not valid: port.id 5

Same thing with trace enabled

[Teascade]

What is your pipewire version? You can get that probably with pipewire --version

That is most confumbling. This is suggesting that somewhere in what you can search with pw-dump as well, there is a property "port.direction": "port.id 2" which is.. odd to say the least..

[UltraBlackLinux]

I'm on 0.3.64

[Teascade]

That is the same version I'm on and also running out of ideas as well.. There is definitely something I've not seen going on. Any chance you could post the pw-dump for any of the ports for these nodes that should be used? I don't have an easy solution for how to find this, for myself I used pw-dump | grep -C 50 PS5Sink and just copied the part. This is what one of the ports I use look like.

  {
    "id": 54,
    "type": "PipeWire:Interface:Port",
    "version": 3,
    "permissions": [ "r", "w", "x", "m" ],
    "info": {
      "direction": "input",
      "change-mask": [ "props", "params" ],
      "props": {
        "audio.channel": "FR",
        "format.dsp": "32 bit float mono audio",
        "node.id": 50,
        "object.id": 54,
        "object.path": "PS5Sink Audio/Sink sink:playback_1",
        "object.serial": 55,
        "port.alias": "PS5Sink Audio/Sink sink:playback_FR",
        "port.direction": "in",
        "port.id": 1,
        "port.name": "playback_FR",
        "port.physical": true,
        "port.terminal": true
      },
      "params": {
        "EnumFormat": [
          {
            "mediaType": "audio",
            "mediaSubtype": "dsp",
            "format": "F32P"
          }
        ],
        "Meta": [
          {
            "type": "Header",
            "size": 32
          }
        ],
        "IO": [
          {
            "id": "Buffers",
            "size": 8
          }
        ],
        "Format": [ ],
        "Buffers": [ ],
        "Latency": [
          {
            "direction": "Input",
            "minQuantum": 0.000000,
            "maxQuantum": 0.000000,
            "minRate": 0,
            "maxRate": 0,
            "minNs": 0,
            "maxNs": 0
          },
          {
            "direction": "Output",
            "minQuantum": 0.000000,
            "maxQuantum": 0.000000,
            "minRate": 0,
            "maxRate": 0,
            "minNs": 0,
            "maxNs": 0
          }
        ]
      }
    }
  }

Important here is that even though you're declaring the node names here, it's actually Ports that are used for linking the audio together. The ports and their directions are the things used for figuring which ports should be connected. Usually the ports do have the same names as the nodes in their port.alias or port.path though, so it is relatively easy to find them.

[UltraBlackLinux]

dump

I hope this helps.

(TIL grep -C exists. Would have saved me a lot of headache earlier)

[Teascade]

I have something in mind that would help debug this a little bit, but for now it seems I'm currently unable to build this project after the most recent pipewire version.

This does seem like a bug though, but I can't quite say where it lies just yet, but I have some doubt that it might be in either pipewire-rs or pipewire itself. Either way I think I might need to create an issue about this on pipewire-rs to figure out further.

[Teascade]

Made an issue about this on pipewire-rs, here's the link in case anyone reading wants to follow that one. Certainly something going on here.

https://gitlab.freedesktop.org/pipewire/pipewire-rs/-/issues/56