Add privacy monitor block

[bim9262]

See #1973

[bim9262]

@MaxVerevkin do you have any tips/recommendations for working with pipewire like setting up a global pipewire client that can be accessed by multiple threads?

I did attempt to make a global client like there is for the pipewire sound module, but ended up getting stuck.

[MaxVerevkin]

I did attempt to make a global client like there is for the pipewire sound module, but ended up getting stuck.

What problems did you encounter? I would imagine if we want to share pipewire connection between blocks, we would need a global Mutex (or RwLock) with the state (nodes, links), global Mutex<Vec<Sender<_>> for event listeners and a global Lazy to spawn the thread only once. This seems similar to pulseoudio.

[bim9262]

I was having a deadlock issue, but I got it sorted out now :)

Looks like a newer version of libpipewire is required than is available in the runner image. Might need to add a step to build it from source.

https://gitlab.freedesktop.org/pipewire/pipewire-rs/-/issues/75

[c3Ls1US]

While not directly related to this functionality, since pipewire will be added as a dependency, I think this would also be a good opportunity to support it as a sound driver as well

[MaxVerevkin]

Looks like a newer version of libpipewire is required than is available in the runner image. Might need to add a step to build it from source.

Would depending on an older version of pipewire crate fix this?

[MaxVerevkin]

While not directly related to this functionality, since pipewire will be added as a dependency, I think this would also be a good opportunity to support it as a sound driver as well

Does it have any advantages over pulseaudio driver, like any additional useful features not available today?

[bim9262]

Perhaps you wouldn't need to run pipewire-pulse (I haven't tried this though)

[ammgws]

Perhaps you wouldn't need to run pipewire-pulse (I haven't tried this though)

Not sure if it's worth the maintenance burden since Pipewire implements the Pulseaudio api, so as you said all those users need to do is install pipewire-pulse if they want to use the sound block

[bim9262]

Looks like a newer version of libpipewire is required than is available in the runner image. Might need to add a step to build it from source.

Would depending on an older version of pipewire crate fix this?

I'm not sure, but I can run a test in another branch.

ETA: I was unable to get it to build with an older version of pipewire and libspa-sys

[c3Ls1US]

Perhaps you wouldn't need to run pipewire-pulse (I haven't tried this though)

Not sure if it's worth the maintenance burden since Pipewire implements the Pulseaudio api, so as you said all those users need to do is install pipewire-pulse if they want to use the sound block

I'm not a PipeWire expert so I cannot provide an informed opinion, but it appears that there are downsides by going through pipewire-pulse.

A few years ago, mpv provided direct support for the PipeWire audio output driver, stating reduced complexity and richer integration as the primary reasons. I can't comment if it'll provide "richer integration" for this project, but certainly targeting PipeWire directly should result in less latency for users because the compatibility layer(s)/intermediate steps would be bypassed.

Aside from that, would it really be a maintenance burden? Along with Wayland, PipeWire in Linux looks to become a standard component to not be a future burden so I believe supporting PipeWire natively will be useful.

[bim9262]

There may be an advantage for mpv as a source of audio to use pipewire over pulse, but any latency issues between pipewire and pipewire-pulse should be moot for our use case. They only real advantage is that you wouldn't need one thread for pipewire and another for pulse within the status bar.

I'm not sure that it's really much of an extra burden to support pipewire for audio info since it's 90% of the way there already.

[bim9262]

After much investigation... I have determined that the pipewire sound block isn't quite as nice as using the pulseaudio version. The main reason is that there's no default sink/source (as far as I can tell). Also if you use a mix of tools and set the pipewire volume it doesn't update the pulseaudio volume, but updating the pulseaudio volume updates both. This leads to odd situations where pipewire thinks the volume is one thing and pulseaudio thinks it's another.

I suppose if you were completely pulseaudio free (which I kinda doubt at this point being all that feasible) then it wouldn't be an issue.

[MaxVerevkin]

After much investigation... I have determined that the pipewire sound block isn't quite as nice as using the pulseaudio version. The main reason is that there's no default sink/source (as far as I can tell). Also if you use a mix of tools and set the pipewire volume it doesn't update the pulseaudio volume, but updating the pulseaudio volume updates both. This leads to odd situations where pipewire thinks the volume is one thing and pulseaudio thinks it's another.

I suppose if you were completely pulseaudio free (which I kinda doubt at this point being all that feasible) then it wouldn't be an issue.

So.. is it worth adding 600 loc? Pulseaudio-free setups don't seem too realistic to me, plus people who use pipewire with pulseaudio compat may set the backend to "pipewire" and, as you described, get mixed results.

[bim9262]

So.. is it worth adding 600 loc? Pulseaudio-free setups don't seem too realistic to me, plus people who use pipewire with pulseaudio compat may set the backend to "pipewire" and, as you described, get mixed results.

I think not. I can drop it especially the way the idle loop works for processing commands is less than ideal.

[MaxVerevkin]

Looks like a newer version of libpipewire is required than is available in the runner image. Might need to add a step to build it from source.

• This should be mentioned in doc/manual_install.md.
• A bit weird idea: maybe we should just switch to Arch on the CI? I did so in https://github.com/MaxVerevkin/ewc because I couldn't install a developer version of some package for some reason.

[bim9262]

• This should be mentioned in doc/manual_install.md.

Updated the doc

• A bit weird idea: maybe we should just switch to Arch on the CI? I did so in https://github.com/MaxVerevkin/ewc because I couldn't install a developer version of some package for some reason.

I update the workflows to use the archlinux image :)

[bim9262]

Interesting that clippy and cargo-test fail since they worked when I pushed them to master on my fork. It says:

All changes made by hooks:
diff --git a/Cargo.lock b/Cargo.lock
index 515d7ca..8a321be 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -2875,7 +2875,7 @@ dependencies = [
  "cfg-expr",
  "heck",
  "pkg-config",
- "toml 0.8.8",
+ "toml",
  "version-compare",
 ]

It doesn't make any sense why that would happen though since there are two different versions of toml in our package.

[bim9262]

It doesn't make any sense why that would happen though since there are two different versions of toml in our package.

There where two versions of toml, but there aren't now. Rebasing and updating the Cargo.lock file fixed the issue (looks like the wrong line was git merged in).

[bim9262]

Just resolved merge conflict in .github/workflows/pre-commit.yml