WirePlumber configuration seams rather brutal. Apart from completely disabling hardware with, for example:
monitor.alsa.rules = [
{
matches = [
{
device.name = "alsa_card.pci-0000_00_1f.3-platform-skl_hda_dsp_generic"
}
]
actions = {
update-props = {
device.disabled = true
}
}
}
]
does there exist a fine grained method to associate sub-graphs?
Replying to my own thread is bad but I am lost.
Reading the pipewire/wireplumber docs and code for the n-th time I see
https://docs.pipewire.org/page_man_pipewire-props_7.html
media.role
The Use case of the media. Possible values include:
Production: Professional audio processing and production.
This clearly seems intended to whitelist endpoints into a compact graph. Wireplumber’s linking script /usr/share/wireplumber/scripts/linking/find-media-role-target.lua tests for the media.role property and looks to automatically connect graph nodes that share the same media.node value.
Yet there is no way to set the media.role value within wireplumber’s configuration, nor is there any example given for this obvious use-case.
Has anybody here been down this path before?
Not an expert, but I did some casual exploration of Wireplumber some time back.
I believe media.role is not set in configuration, but is a property of a stream that is set by the application.
For instance, you can start a pipewire stream with a specific media.role as follows:
pw-play --media-role "Notification" $file
What to do with that within Wireplumber is set in configuration by the policy, for example in /usr/share/wireplumber/scripts/restore-stream.lua
...
rs_metadata = ImplMetadata("route-settings")
rs_metadata:activate(Features.ALL, function (m, e)
if e then
Log.warning("failed to activate route-settings metadata: " .. tostring(e))
return
end
-- copy state into the metadata
moveToMetadata("Output/Audio:media.role:Notification", m)
-- watch for changes
m:connect("changed", function (m, subject, key, type, value)
handleRouteSettings(subject, key, type, value)
end)
end)
...
That’s about the extent of my knowledge on the subject, and that is pretty sketchy, but I hope it helps.
Cheers,
Keith
Also, bear in mind that a primary use-case for WirePlumber is automotive (e.g. AGL) where the applications are tightly controlled and making them pipewire-aware is relatively easy.
In this case, using media.role to differentiate between things like notifications and other media is important.
For a standard Linux desktop, most applications don’t know about Pipewire and won’t be setting Pipewire-specific attributes like media.role.
As such, I think there’s not really a useful benefit to media.role or for related WirePllumber configuration relating to Ardour or other music production applications at this time
Maybe you could step back and describe what you are trying to achieve. It may well be that some other mechanism would be more appropriate, such as ALSA UCM or .asoundrc configuration, or direct pulse audio/pipewire config.
I went through a lot of hoops trying to tame my 18 channel mixer to be useable in both a desktop environment and as a multi-channel device for audio work. The solution I settled in had a few compromises, but these were down to the way Linux audio works in general.
I looked at various approaches, and quickly decided that WirePllumber was not the right option.
Cheers,
Keith
I think I’m getting close to my goal of ardour connecting to a minimal graph.
I have accepted that pipewire is the linux media framework going forward.
There must be a canonically correct way to isolate real-time audio streams from bullshit like the system bell and wireless headphones.
The designers have suggested the “media.role=Production” keyword pair for Professional audio processing and production and I intend to use it.
Or I will file a bug with the pipewire devs against the deficiency.
Fine, but it was just a suggested use-case. They don’t say this should work in practice with current applications.
The reality is, to make this work ideally (which appears to be your aim) you require all of the applications to be Pipewire-aware and to use the Pipewire API correctly and fully.
This is NOT the case.
Ardour does not, to my understanding, use Pipewire in this way. And neither does any other music production application, or any other application in general (aside from those that are specifically designed to control Pipewire or it’s predecessor, Pulseaudio).
So, without this metadata, you are very limited in what you can achieve and how you achieve it.
It may be possible, for example, to write a WirePlumber policy which is based on specific applications (e.g. looking for the application name “ardour”) and which then adds the “media.role=Production” attribute to it.
What deficiency?
I see no bug here.
Cheers,
Keith
For applications this is documented in PipeWire: client.conf
# ~/.config/pipewire/pipewire.conf.d/10-ardour-streams.conf
#
# configuration file for tight ardour graph
# consult 'coppwr' for parameter correctness
#
# ref:https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis
#
# systemctl --user restart pipewire.socket pipewire.service wireplumber.service
stream.rules = [
{ matches = [
{
application.process.binary = "~ardour.*"
}
]
actions = {
update-props = {
media.role = "Production"
}
}
}
]
I am getting close …
Well, good luck with the project. I hope that, if you succeed (or, maybe, even if you don’t) you document this somewhere, as it may be useful for others going forward.
Cheers,
Keith
When I read posts like this it makes me want to run screaming back to Windows 10 (where Ardour, Kdenlive et al run very well incidentally)… 
Is simply using Ardour with ALSA not an option? As far as the old I-need-to-watch-Youtube-while-I’m recording-in-Ardour thing I personally find on the very rare occasions when this is needed watching a YT tutorial on my smartphone beside my keyboard and running Ardour with ALSA completely eliminates the need to bother with ANY of these troublesome Desktop Audio servers… I can hardly wait for all the fun Wayland is going to be… 
From my point of view, I never could find a suitable audio setup for my device on Windows whereas ALSA and Pipewire gave me the ability to fine tune the device appearance to work pretty seamlessly regardless of whether I’m using desktop audio apps, or Ardour.
The main problem is actually the daily use with desktop apps. I use a Behringer XR18 which is set up with channels 17 and 18 being the speaker outs (and, in the other direction, the stereo mix input). Out of the box, this is seen (both by Linux and Windows) as a multi-channel audio interface with the assumption it’s a surround system. I can change this, but it then defaults to using channels 1 and 2 and I have to keep manually changing the connection.
I couldn’t find a good solution to this on Windows. Having said that, I’ve been a Linux desktop user for 20+ years, with my Windows use being occasional and sporadic. I did a fair amount of research into a solution but, as I knew it wasn’t going to be something I used that much, I eventually gave up. More recently, my current desktop rig doesn’t even have Windows installed.
Finding the right solution on Linux (creating a virtual device) was, admittedly, a faff, but once I worked it out it worked pretty seamlessly, and I’ve been using that config for around 7 years now, across OS updates, re-installs, and even OS changes.
Regarding the OP and WirePlumber I know some people do this sort of thing, not because they don’t have an easier way to do it, but because they like to tweak, learn something new and, perhaps, find cool, clever, and useful ways to do stuff. For some people, it’s the joy of having something like Linux where you can do this.
I don’t know if that’s the case here.
I must admit, when I first looked at Pipewire and WirePlumber, I thought: there’s some cool possibilities right there. What made me abandon it was the lack of stability (at the time) the lack of tutorials, and the fact that most desktop apps don’t directly integrate with Pipewire or Pulseaudio using the full API.
And, at that point, I needed a solution that I could implement quickly because I was doing daily video calls and needed desktop apps to work.
I am also thinking that if the OP came up with something clever, it might be something that might morph into a standard configuration for a music-focused OS, along with some configuration utility support.
I think Pipewire is a powerful capability and, if it continues to develop and improve, I think we could approach the point where Linux users have a standard low-latency audio environment that’s more powerful than Mac or Windows (I already think we are there compared to Windows).
Cheers,
Keith
Hi Keith,
Don’t take me too seriously I’m a tweaker too (not in the drug sense of the word). I obviously couldn’t do what I do in AVL without a lot of tweaking. Linux has me addicted to right-click File Manager actions and I miss them dearly when I’m doddling around in Win 10. However when I see the complexity that PipeWire requires to customize outside it’s defaults it is rather offputting, I’m sure actual developer types don’t find the need to become conversant in lua simply to change the Audio setup that odd but from the outside looking in it seems pretty insane…
I hear you, and I wish it was easier.
But the way I see it, it’s still fairly early days for Pipewire, and it’s only just (in the last 2-3 years) getting to the point that it’s a standard on mainstream desktop Linux distros.
There’s still a way to go before it’s as slick to “normal” users as it could be. And realise that’s off-putting to many users.
But we, as a community, are still finding our way around what is a very powerful but, also, very complex environment.
Of course, I don’t need to tell you that.
As you know, a lot of what ships with distros is “opinionated configuration” and, if done well, this is largely invisible to most users, as it should be.
But developing those configs to the point where they can become invisible and can handle all the important use-cases takes time.
I get the impression, from my own exploration, that WirePlumber is a powerful capability that is underutilized on the Linux desktop. It may have the potential to support some powerful, invisible, under-the-hood collections of configs that ships with future distros.
If the OP is just looking to solve a problem then I think it’s the wrong approach. But if they are looking to develop something new and cool, then they could well be doing a valuable service to the wider community.
Cheers,
Keith
Yeah. Its insane. The configuration is spread around like dandelion seeds in a hurricane.
its complicated because it needs to be. There is a lot going on.
I’m making progress. This is a task I was forced into by a new device that broke a years old working jack configuration.
I expect that once I get partitioned graphs fixed the solution will work for years again.
Maybe today? I’d like to move on from this.
OK. I’ve made my experience with pipewire+wireplumber, all mixed together in a bucket with the eggs on top.
Pipewire’s jack implementation is insensitive to the linking rules of wireplumber, and freely instanciates nodes for every source and sink cataloged in the d-bus dictionary, regardless of their differing hardware capabilities.
It is possible to blacklist devices or nodes that but just removes them from d-bus so they won’t be instantiated. Removing devices from d-bus breaks the desktop.
So its a one size fits all situation. There is no way to hint pipewire which hardware the jack graph should run on. The wireplumber session manager cannot manage jack or jack_midi nodes, it just makes consumer audio/video connections.
All that metadata is just there to duck the system bell from your wireless headphones.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.