TL/DR: This PR enables any pipewire on the local network to send its audio to snapcast. Just pick snapcast in your audio mixer:

Prior

As discussed in #821, PipeWire can now automatically discover PipeWire server instances and register a new TCP stream to it. This works, but if you are using meta streams, it will be created outside of it, and it's currently not possible to do otherwise.

This is because meta streams are built at startup from their definition specified in the configuration file, and at startup, the pipewire stream does not yet exist, and so cannot be added.

In other words, this currently fail:

source = pipe:///tmp/snapfifo?name=default
source = meta:///default/PipeWire-Jerome-PC?name=meta

because PipeWire-Jerome-PC does not exist at startup.

Fix

• Meta stream can now be created empty.
• Meta stream sources are lazily created.
  • If a source in the meta's config does not exist at startup, it will only be added when created.
• Bonus: Add a catch-all wildcard operator to meta streams. Example:

source = pipe:///tmp/snapfifo?name=default
source = spotify:///librespot?name=Spotify
# The meta stream will include Spotify, default, and any stream created later on.
# Spotify will be prioritized, then other streams in creation order.
source = meta:///Spotify/*?name=meta

This is in its own commit and can easily be removed if you disagree.

What does not change

Everything else:

• If a source exists at startup, the behaviour is the same.
• A source not specified in a meta stream config file will never get added to it.
• The same ordering behaviour applies. Example:

source = pipe:///tmp/snapfifo?name=default
# At startup, default will be the active stream, but if `PipeWire-Jerome-PC` ever get created, it will take priority.
source = meta:///PipeWire-Jerome-PC/default?name=meta

I think this PR partly fixes #1232 when PipeWire is used.

Pull Request Checklist

• Done