No updates in `listen` when switching between microphones

[marioortizmanero]

The PR #64 introduced the on client pattern to the command in grep. However, that ends up consuming lots of CPU power even when the script isn't being used. For instance, I get on client events when playing music, which shouldn't update.

The easy fix would be to just remove on client from the patterns. However, we added that because without it, the microphone listen function didn't work in some specific cases. I'm still not sure which cases these are, though.

This was reported by Viterzgir at https://aur.archlinux.org/packages/pulseaudio-control.

/cc @Aerion

[marioortizmanero]

Can confirm that removing on client fixes the issue. I can release a new version without it for now, but that breaks listen for microphone switching on my machine...

[marioortizmanero]

I guess the only solution is to have a named FIFO or similar where we notify of our own events, and then we could also read from it in listen.

Another option is to report this behavior in pactl as a bug, but it might actually be how it's supposed to work. We could figure out another way to get notified of events that does work and investigate more, because I'm not actually sure why this happens.

We can't use polybar's integrated IPC here because we should also update when events occur outside the script.

[Aerion]

If it leads to high cpu, I agree that it would be better to remove listening on on client for now, push a quick fix, and find a clean way to have the microphone feature working.

[marioortizmanero]

On it, that'll be v3.0.1.

[Aerion]

FYI in i3blocks-contrib, they're filtering on Event 'change' (which is not triggered by the client events). So I guess the same issue would be present with your setup.

Another option is to report this behavior in pactl as a bug, but it might actually be how it's supposed to work.

I quickly tested python-pulse-control which subscribes to PulseAudio's events via the C api, and I see the same events as pactl subscribe (just in a different format). So, it may be (to verify) that pulseaudio doesn't emit events on default source being set, and not an issue with pactl. Then, it may be an expected behavior 🤷

In fact, I think we're both running pipewire, it may be an issue with pipewire-pulseaudio's implementation, something like https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1391

[marioortizmanero]

Yeah a good idea would definitely be to see if this still happens with raw pulseaudio, rather than pipewire. I'll try it when I have a bit more time. It would also be interesting to actually learn how pactl subscribe works, which isn't described very well in the docs.

If the behavior is different we can report it as an issue, but I'm guessing that will take time to release in a new pipewire version anyway.

[lzhoucs]

I am using raw pulseaudio and can confirm it's working for me. So this issue might only affect pipewire users. Also noticed one minor documentation thing, --node-blacklist should be used for next-node rather than listen for the --node-type input example:

# Use --node-blacklist to remove the unwanted PulseAudio .monitor that are child of sinks
exec = pulseaudio-control  --node-type input ... --node-blacklist "*.monitor" listen

[marioortizmanero]

Hah, I think this was fixed in the last pipewire version, 0.3.54. I was checking out the release notes and they include:

Card properties are now also added to sinks and sources, just like in pulseaudio.

I have updated and it does work for me, at least. Can you confirm, @Aerion?

[Aerion]

Hah, I think this was fixed in the last pipewire version, 0.3.54. I was checking out the release notes and they include:

Card properties are now also added to sinks and sources, just like in pulseaudio.

I have updated and it does work for me, at least. Can you confirm, @Aerion?

On my side, muting triggers a change on source/card, but switching sink if I never played a sound, or switching input only triggers the change on server event.

Thus the on client doesn't seem necessary.