4 ms·

Big fan of PipeWire, although I wish the tooling could work directly with PipeWire, instead of going through pactl. It's there, it's just not user-friendly. I e

Big fan of PipeWire, although I wish the tooling could work directly with PipeWire, instead of going through pactl. It's there, it's just not user-friendly. I ended up writing a tool for changing volume/muting that directly uses pw-cli: https://github.com/smasher164/pw-volume https://github.com/smasher164/pw-volume.

danShumway 5y ago
Agreed, at least to a certain degree :) I never really got good with pactl or the various other interfaces, so while it's great that Pipewire is compatible with them, I was also hoping that Pipewire would mean I never needed to get comfortable with them. If I have any criticism of Pipewire, it's that as someone who is not really interested in learning all of the quirks and weirdness of the old systems and would happily never really learn those systems except for older compatibility reasons, it's slightly weird to be running Pipewire and have all the tutorials that I've run into around it still start with, "let's learn some Pulseaudio commands".
Arnavion 5y ago
You can also munge the pw-dump output with jq, instead of needing something to be compiled. pw-dump | jq ' ( .[] | select(.type == "PipeWire:Interface:Metadata") | (.metadata // [])[] | select(.key == "default.audio.sink") | .value.name ) as $default_sink_node_name | .[] | select(.info.props["node.name"] == $default_sink_node_name) as $default_sink_node | . '
- smasher164 5y ago
  Yes. This is how I did it initially, before rewriting it using serde. However, as I mention here (https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3p3c/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3...), shell with jq was too slow -- particularly if you're holding down the volume key.
  - Arnavion 5y ago
    Ah, good to know. I didn't think it would be noticeably slow, especially given it still has to spawn `pw-dump` and `pw-cli`. But I guess `pw-dump` outputs so much that speeding up just the JSON munging is still worth it. BTW, you may consider using `Cow<'a, str>` instead of `&'a str` for the deserialized fields. For JSON strings that have escapes, serde can't deserialize them into a `&'a str`, so the whole deserialization will fail. `Cow<'a, str>` still works with `#[serde(borrow)]` in that strings that can be deserialized in-place will be the `Borrowed(&'a str)` variant, and only strings that can't will be `Owned(String)` (there's a special borrow-specific deserializer of Cow inside serde to achieve this).
  - faho 5y ago
    jq is surprisingly slow. I've had success calling python to parse some json from a shell script instead of jq.
WhyNotHugo 5y ago
I agree that tooling is still quite raw (e.g.: the Rust bindings don't expose the muted states or volume of anything), but developer documentation is even worse. There doesn't seem to be ANY public documentation on the pipewire API protocol. There's just docs for the C bindings, but lack of protocol documentation is a bit worrying, since none of us can write tools that talk to the server. A LOT of documentation pages are literally empty (just a title an nothing else). This includes the documentation for the native protocol, in case you wanted to write your own client: https://docs.pipewire.org/page_module_protocol_native.html https://docs.pipewire.org/page_module_protocol_native.html Apparently, reverse engineering the client/server implementations is the way to go right now.

danShumway 5y ago

Agreed, at least to a certain degree :) I never really got good with pactl or the various other interfaces, so while it's great that Pipewire is compatible with them, I was also hoping that Pipewire would mean I never needed to get comfortable with them. If I have any criticism of Pipewire, it's that as someone who is not really interested in learning all of the quirks and weirdness of the old systems and would happily never really learn those systems except for older compatibility reasons, it's slightly weird to be running Pipewire and have all the tutorials that I've run into around it still start with, "let's learn some Pulseaudio commands".

Arnavion 5y ago

smasher164 5y ago
Yes. This is how I did it initially, before rewriting it using serde. However, as I mention here (https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3p3c/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3...), shell with jq was too slow -- particularly if you're holding down the volume key.
- Arnavion 5y ago
  Ah, good to know. I didn't think it would be noticeably slow, especially given it still has to spawn `pw-dump` and `pw-cli`. But I guess `pw-dump` outputs so much that speeding up just the JSON munging is still worth it. BTW, you may consider using `Cow<'a, str>` instead of `&'a str` for the deserialized fields. For JSON strings that have escapes, serde can't deserialize them into a `&'a str`, so the whole deserialization will fail. `Cow<'a, str>` still works with `#[serde(borrow)]` in that strings that can be deserialized in-place will be the `Borrowed(&'a str)` variant, and only strings that can't will be `Owned(String)` (there's a special borrow-specific deserializer of Cow inside serde to achieve this).
- faho 5y ago
  jq is surprisingly slow. I've had success calling python to parse some json from a shell script instead of jq.

WhyNotHugo 5y ago

I agree that tooling is still quite raw (e.g.: the Rust bindings don't expose the muted states or volume of anything), but developer documentation is even worse. There doesn't seem to be ANY public documentation on the pipewire API protocol. There's just docs for the C bindings, but lack of protocol documentation is a bit worrying, since none of us can write tools that talk to the server. A LOT of documentation pages are literally empty (just a title an nothing else). This includes the documentation for the native protocol, in case you wanted to write your own client: https://docs.pipewire.org/page_module_protocol_native.html https://docs.pipewire.org/page_module_protocol_native.html Apparently, reverse engineering the client/server implementations is the way to go right now.