Pipewire source option stopped working with last update

[Holbormon]

Hi,

Before updating to the last release, the following config used to work to visualise the soundcard's microphone:

[input]
method = pipewire
source = alsa_input.pci-0000_00_1f.3.analog-stereo

But now, no sound is picked up anymore, as if source was incorrectly set. While debugging, I found out that the source entry above was technically set to node.name as printed by wpctl inspect, so I tried object.path and object.serial as stated by the README, but doing so did not resolve the problem.

Under the current release, the only thing that results in proper sound pickup with this device is switching method to pulse and using node.name. Here is an excerpt of wpctl inspect on the device of concern:

node.name = "alsa_input.pci-0000_00_1f.3.analog-stereo"
node.nick = "ALC1220 Analog"
node.pause-on-idle = "false"
object.path = "alsa:acp:PCH:0:capture"
object.serial = "54"

OS: ArchLinux 6.16.8-arch2-1
cava package from official extra repositories

[karlstav]

Any ideas @pallaswept? Didn't you make the changes here?

[pallaswept]

Any ideas @pallaswept? Didn't you make the changes here?

I did. I'll drop everything and get this working. I'll also subscribe to the issues here so I catch it if any others come up.

This is working here, though. OP's source seems to be correctly set, so I don't think that's the problem. A quick look at something like qpwgraph should confirm that, though.

@Holbormon does source auto_input function correctly? (it should capture sound from the default input device)

Did you try to set active=1? This is required for cava to capture audio from the device if no other applications are recording from it (otherwise the device will become idle and suspended until an active node is capturing from it, and then cava will show the audio which that application captures). Alternatively you could try just recording from the device and seeing if cava shows the audio then.

Is the device shown in pw-top with an 'R' in the left column? Is cava listed there as a follower (has a + before the name) of that device (listed below that device)? Does cava also have an 'R' in the left column? Is the number in the ERR column on both nodes, a 0?

We'll figure this out :)

[Holbormon]

Thank you for the quick and detailed intervention !

First, I can confirm that auto_input does not change anything, and that qpwgraph does show that cava is listening to the right device.

Secondly, here's what happens when 1. recording from another device simultaneously and 2. adding active = 1:

1. pw-top shows 'R' next to the device, cava is NOT a follower, no sound is picked up
2. pw-top shows 'R' next to the device, cava IS a follower, sound is picked up

Thank you again for all the details about the different debugging tools, I didn't know about the existence of pw-top, or auto_input which will greately improve the portability of my config files !

---

EDIT: I later realised that in scenario 1. cava IS actually following the mic, but pw-top doesn't display it as such until the recording device becomes active at least once. I suspect it's a limitation of pw-top itself not being able to tell things about suspended devices.

[Holbormon]

On a separate note, I could swear that before updating, sound was picked up without active = 1 and seemingly without anything recording. This would suggest active = 0 perhaps became a new default in v0.10.6, prior to which the default behaviour was to always record ?

[pallaswept]

OK thanks for the info, we're getting somewhere. 2) at least tells us that it will work when everything is right, but the 1) scenario is the interesting one as it shows that for some reason, everything's not right.

Trouble is, I can't reproduce this here. I'm using cava to monitor my mic, and have set active=0, so cava doesn't do anything when I'm not recording from the mic. When I start capturing from the mic (I used this page to test it just now) the webpage is an active client, which makes the device active, which makes cava active, and I see cava doing its thing when I talk. (FWIW with active=1 I just see it full-time as expected)

The really odd thing about scenario 1) is... I'm not sure how it is possible that cava is linked to this device, the device can be active, but cava still be passive. That's kinda not how that works :D Are you sure we're looking at the right device here? (I mean, you are capturing the same input device that cava is linked to?)

Just for explanation, quotes from the upstream docs about what cava's active setting does. Basically, it's the inverse of the node's passive property.

The node.passive property instructs the session manager to create passive links between the stream and the device node so that, when nothing is connected to the source, both streams will idle (and suspend if the session manager has this configured).
A passive link will keep both nodes it links inactive unless another non-passive link is activating the nodes.

So basically, when a bunch of nodes are linked together, if any one of them is active, it will make them all active. If you start recording with some app then it will be active, so it will make its links to the device active, activate the device, and that's linked to cava, so it should become active, too. When a node is active you'll see it in pw-top with status R(un) and otherwise they will be I(dle) and then S(uspended)

Regarding the defaults, I wondered about that too. I pondered whether maybe you used to have an app recording that device unbeknownst to you, and it stopped when the update with cava came along.... But maybe we changed the defaults. Honestly we discussed a lot of little details and I forget that one, but I will go through our chats shortly, and see if I can figure out if (and if so, why) we changed it.

As for the rest of this, stay confident - we have the same sound card, I know the code fairly well by this point, and if all else fails, there is also pw-dump and pw-mon, which will tell us everything, but they are SUPER verbose (open a new terminal if you want to try it) so I'm just trying for easy answers first :)

[Holbormon]

Digging further, here's the full output of pw-top when an application is recording audio. Cava is set as a follower, but is Suspended for some reason, resulting in all-zero output.

[pallaswept]

OK that's really odd. I'm not sure how that's even possible. As you can see the device is running and per the docs quoted above and confirmed on my machine it should have activated cava, I'm honestly a bit stumped here. I'm running tumbleweed with git pipewire and wireplumber, so we both will have the latest versions of all that.

I'm going to mess with my config a bit and see if I can reproduce this somehow but if you have any ideas I am all ears.

pw-cli info 101 might be helpful if you wouldn't mind grabbing that for me? (change '101' for whatever cava's ID is if you've restarted cava since)

[Holbormon]

Here comes the output of pw-cli info on cava:

        id: 103
        permissions: rwxm-
        type: PipeWire:Interface:Node/3
*       input ports: 2/65
*       output ports: 2/0
*       state: "suspended"
*       properties:
*               media.type = "Audio"
*               media.category = "Capture"
*               media.role = "Music"
*               node.latency = "512/44100"
*               node.passive = "true"
*               node.virtual = "true"
*               stream.dont-remix = "false"
*               channelmix.upmix = "true"
*               media.name = "cava"
*               stream.is-live = "true"
*               node.name = "cava"
*               node.want-driver = "true"
*               node.autoconnect = "true"
*               media.class = "Stream/Input/Audio"
*               port.group = "stream.0"
*               adapt.follower.spa-node = ""
*               object.register = "false"
*               factory.id = "9"
*               clock.quantum-limit = "8192"
*               node.loop.name = "data-loop.0"
*               library.name = "audioconvert/libspa-audioconvert"
*               client.id = "81"
*               object.id = "103"
*               object.serial = "2651"
*               node.driver-id = "45"
*       params: (9)
*         3 (Spa:Enum:ParamId:EnumFormat) r-
*         1 (Spa:Enum:ParamId:PropInfo) r-
*         2 (Spa:Enum:ParamId:Props) rw
*         4 (Spa:Enum:ParamId:Format) -w
*         10 (Spa:Enum:ParamId:EnumPortConfig) r-
*         11 (Spa:Enum:ParamId:PortConfig) rw
*         15 (Spa:Enum:ParamId:Latency) rw
*         16 (Spa:Enum:ParamId:ProcessLatency) rw
*         17 (Spa:Enum:ParamId:Tag) -w

[pallaswept]

OK I've managed to reproduce this.

edit: ignore that mine's called 'cava record', it's the same as normal, I just have the name set so I can identify it and arrange it in qpwgraph and stuff

Super strange, it only happens on this device. Bear with me while I dig.

[pallaswept]

OK I know why this is happening and how it got to this point. TL;DR for you @Holbormon is that you should set active=1 at least for now, everything should work as it did before.

I'm not certain about this, but it seems like we may have found a bug in wireplumber or maybe pipewire. The shortest way I can think to explain this is that if we do the same thing we both screenshotted in pw-top above, but with an output device, it works as intended -
cava is passive, the device is passive, then we link a client to the device, the client is active, it makes the device active, that makes cava active.

When we do it with an input device -
cava is passive, the device is passive, then we link a client to the device, the client is active, it makes the device active, and that does not make cava active.

I'll do a little more testing on my side and then raise this upstream and let you know what I find out.

Apologies for missing this. Most of my testing was on output devices as that's what most people would use (ironically not me hah) and when I tested on input devices, wireplumber was injecting my smart filter inbetween cava and the actual input device node, and masking this behaviour we're seeing now... Which is odd because it does that even if the filter is passive, like the device, but they behave differently, which really makes this seem like a bug.

[Holbormon]

Thank you for taking the time to summarise your findings ! I concur with the conclusion that active = 1 exactly restores the previous behaviour, and I'm now pretty certain* that this was an implicit default prior to v0.10.6, hence why I missed the bug until now.

For this reason, if you are convinced the issue is upstream we can probably close this one. However, I'd still be interested to follow whatever upstream discussion results from your findings over at pipewire/wireplumber, because it turns out that I could end up using active = 0 in the future.

Could you link to it here if something happens ? Thanks !

---

*Basically I'm using an independent mic use indicator in which I used (prior to the update) to have to whitelist cava for it not to show up when nothing was happening, and after updating I now notice that whitelisting cava is not strictly needed anymore, despite not having changed my cava config.

[pallaswept]

Yeh I definitely need to follow up on this some more.

We may want to change the default, perhaps also depending on what happens upstream. Perhaps we might want to make the nodes active by default, or perhaps only by default on input devices.

On input devices (presuming everything is working) it's more a matter of personal taste - do you want the mic recording and cava to display it, even if you're not recording? active=1, otherwise active=0... but for output devices it's pretty much always better to be passive (prevents waking the graph when nothing else is happening, saving CPU, but always wakes up when anything is playing).

I've filed an issue with wireplumber here but I'll definitely bring back any news to this project because it will dictate my next steps.

[pallaswept]

Aha, I just knew we had talked about the default behaviour. Found the relevant commit: b0cd89e

But I've goofed and missed a spot because while it does use the original settings if the config file is missing them, the new config file has the reversed preferences: e4fa42f#diff-674abfe0ee3a6520f980b729c04aebd2bc63bcee505f91622c62da2f64fc5518

So it's opt-in as intended, with existing config files which lack the settings, but if the settings from the config file are added, or if it's a new config file, it's going to use the new features. @karlstav should I file a CR to fix that?

[karlstav]

yea they seem to all be the reversed of what we intended. How did we managed that,

the old behavior "active" (always process) was on. Here the default is set to 0, the commented out default value in the config is also zero.

It will not use the original settings if the config file is missing, the default is 0:

cava/config.c

Line 994 in f855c78

p->active = iniparser_getint(ini, "input:active", 0);