Static and persistent links to client streams, that are only distinguishable by their corresponding application.process.id property

I don't think there's enough data for automatic stream restore to work. As such you'd likely need to have each client specify the target.object of the sink they'd like to output to and that might work. The only problem here might be that I'm not sure if clients using the ALSA API can specify their desired target.object property. If snapcleant has PulseAudio API support, then it should be able to specify the sink it would like to use and it should just work.

In your case the sinks are likely unique enough that it won't be a problem but if the sink names are not stable (perhaps two identical devices), then of course this could still fail by mixing up the targets.

You could inject some unique property to each of the snapclient streams from the process that spawns them, using the PIPEWIRE_ALSA environment variable, given that snapclient seems to be using the pipewire-alsa plugin.

Injecting through PIPEWIRE_ALSA env does indeed add a unique property to the snapclient. Now how do I make sure, to add the target.object property accordingly to the streams?

changed the description

For future reference:

This quick & dirty lua script picks up the target.object property of the parent client object (injected through PIPEWIRE_ALSA env as suggested by @gkiagia), once a stream was added and sets/updates the metadata for the stream node.

static.lua

default_metadata_om = ObjectManager {
  Interest {
    type = "metadata",
    Constraint { "metadata.name", "=", "default" },
  },
}

node_om = ObjectManager {
  Interest {
  type = "node",
    Constraint { "media.class", "matches", "Stream/*", type = "pw-global" },
    Constraint { "application.name", "equals", "snapclient", type = "pw-global" },
  },
}

client_om = ObjectManager {
  Interest { 
  type = "client",
    Constraint { "application.process.binary", "equals", "snapclient", type = "pw" },
  }
}

function getClientProps(cid)
  local client = client_om:lookup {
	  Constraint { "bound-id", "=", cid, type = "gobject" }
  }
  return client.properties 
end

node_om:connect("object-added", function (om, obj)
metadata = default_metadata_om:lookup()
metadata:set (0, "default.audio.sink", "Spa:String:JSON", Json.Object { ["name"] = "" }:to_string ())
p = getClientProps(obj.properties["client.id"])
to = (p["target.object"])
Log.info ( 'setting node ' .. obj.properties["node.name"] .. ' (nodeID:  ' .. obj["bound-id"] .. ') to: ' .. to )
metadata:set (obj["bound-id"], "target.object", "Spa:Id", to )
end)



default_metadata_om:activate()
client_om:activate()
node_om:activate()

To make this work, the following changes have been made:

wireplumber.conf: to avoid picking default target node for linking comment out line
```
{ name = linking/find-default-target.lua, type = script/lua, priority = 100 }
```
add this line to the wireplumber.components section
```
{ name = static.lua, type = script/lua, priority = 100 }
```
find-best-target.lua: to avoid that atleast one target is picked if defined target is not present comment out lines 78-68:

if (target_picked == nil or
    priority > target_priority or
    priority == target_priority and plugged > target_plugged)) then
 Log.debug ("... picked")
 target_picked = target
 target_can_passthrough = can_passthrough
 target_priority = priority
 target_plugged = plugged
end

policy.conf

wireplumber.settings = {
  ## Moves session items when metadata target.node changes
   policy.default.move = true

  ## Moves session items to the default device when it has changed
   policy.default.follow = false
...
}

Certainly this is not a very elegant solution but for now it works according to my tests. Feel free to comment

If you are working with the 0.5 branch, you can also re-write your script to provide a hook that can be injected before find-default-target.lua and avoid hacking the rest of the scripts. I have kept a note to write an example based on your use case, in the documentation.

That certainly sounds like a more elegant solution. I’m currently studying the documentation and looking forward for an example

added area::documentation area::policy-desktop type::suggestion-request labels

Static and persistent links to client streams, that are only distinguishable by their corresponding application.process.id property

Designs

Child items ...

Activity

Admin message

Admin message

Static and persistent links to client streams, that are only distinguishable by their corresponding application.process.id property

Activity