Pipewire support

As of Pop-os 22.04 is using Pipewire instead of Pulseaudio. While pipewire should be backwards compatible rwaybar no longer shows the volume as of Pop-os 22.04. Most distros plant upgrade to upgrade to pipewire sometime in the future.

As a first step I think rwaybar would need a clear API for the audio back-end. Then the first implementation could use a compile time feature to switch between implementation. Later it could be auto detected.

An alternative would be figuring out why the volume is not shown on Pipewire even though it should be backward compatible.

Pipewire supports the pulseaudio APIs for controlling volumes, and I believe this mechanism is still recommended by the pipewire authors (see https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use). I use pipewire on my system and it works for me.

Must be a bug in either Pop-os/pipewire or rwaybar then. Ill sprinkle some dbg! expressions through pulse.rs and report back

I could also write up a PR adding runtime configurable tracing/logging using either the log or tracing ecosystem. Let me know it that sounds useful.

FYI: RUST_LOG=debug rwaybar already exists, though the documentation of this might need adding.

FYI: RUST_LOG=debug rwaybar already exists, though the documentation of this might need adding.

Thanks! I don't know how I missed that!

Regarding documentation maybe an issue template here on GitHub is an idea. You could request each bug to be accompanied with a log.

I was able to investigate this a little, adding some logging to: https://github.com/danieldg/rwaybar/blob/1094cb6bee68ce8f58e2d0a90f8367443edaf2c7/src/pulse.rs#L534

Specifically:

dbg!(port.volume).avg();
dbg!(port.volume.avg());
let volume = Volume(5000u32);
trace!("volume string: {}", volume.print().trim());

I hard coded the volume to make sure I was at the part of the code where the new volume is set.

I changed my volume as I usually do using pw-volume. It is a wrapper around pw-cli.

Results

Running with RUST_LOG=trace,mio::poll=warn cargo r resulted in:

[src/pulse.rs:566] port.volume = ChannelVolumes {
    channels: 2,
    values: [
        Volume(
            65536,
        ),
        Volume(
            65536,
        ),
        Volume(
            0,
        ),
       // about 30 more Volume(0) values.
    ],
}
[src/pulse.rs:567] port.volume.avg() = Volume(
    65536,
)
[2022-05-11T23:03:00Z TRACE rwaybar::pulse] volume string: 8%

This shows that pulse is passing a volume of 65536 aka 100%. I changed the volume while testing and it stayed at 65536. I had youtube playing over speakers while testing, the volume of the music did change.

Conclusion

rwaybar is recieving the change event however the data from pulseaudio does not reflect the correct volume. This could be a bug in pipewire. @danieldg you also use pipewire but without issue, how do you change your volume?

Solutions

• continue using the existing code to detect changes but query the data from pipewire
• use another method for volume changes

Todo

investigate if this issue is shared with other ui's (gnome, kde etc) when setting volume through pipewire. I have no more time today but I'll see what I can do tomorrow.

I use pulse to change volumes:

bindsym --locked XF86AudioRaiseVolume exec pactl set-sink-volume '@DEFAULT_SINK@' '+5%'

There are multiple "volume" knobs present in the pipewire (and pulse) path; I wonder if you are adjusting a different one than pulse is querying? You can scroll up and down on the default items on the bar to adjust their volumes using the pulse API. When I do so, I can observe changes in the following pipewire volume knobs:

pw-dump|jq '.[]|select(.type == "PipeWire:Interface:Device")|[.info.params.Route[0].name, .info.params.Route[0].props.channelVolumes]'

Correction: the example config did not include scrolling to adjust volumes; this has now been added.