Idle protocols: Successsful audio idle inhibit anyone?

[plum]

I'm lookng for a successful strategy to inihibit idle whilst playing audio, and if you have one please do tell. Below, I detail my unsuccessful attempts, and what I understand.

I am using swayidle which determines idle timeout before dpms off, and suspend; In order to inhibit swayidle when playing audio I tried two alternative scripts, sway-audio-inhibit and waylpand-pipewire-audio-idle-inhibit,

Audio plays through pipewire. I have pipewire-pulse and pipewire-alsa service files enabled.

I read that Niri,

"implements the ext-idle-notify and idle-inhibit pair of Wayland protocols. This allows tools like swayidle to work, and clients like mpv to pause them from working while you're watching videos".
" has "implemented the org.freedesktop.ScreenSaver D-Bus interface for idle inhibiting, used by xdg-desktop-portal-gtk"

And yes, to confirm, I find idle is nicely inhibited as desired and expected when playing videos in browsers ( qutebrowser, brave) and, also mpv.

I'm wondering if ext-idle-notify and idle-inhibit Wayland protocols include zwp_idle_inhibit_manager_v1 :

From the README, of Sway-audio -idle-inhibit

"Prevents swayidle from sleeping while any application is outputting or receiving audio. Should work with all Wayland desktops that support the zwp_idle_inhibit_manager_v1 protocol but only tested in Sway"

From Wayland PipeWire Idle Inhibit:

"Description
Suspends automatic idling when media is being played through Pipewire.

For detecting media being played, it depends on PipeWire.

For inhibiting idle, it depends, either on:

Wayland compositors implementing the experimental protocol idle-inhibit-unstable-v1
Daemons implementing the D-Bus org.freedesktop.ScreenSaver service"

I haven't installed (available in arch user reporitory ) the xscreensaver-dbus-screenlock package, which perhaps could help there, but I doubt it; I'm running niri-session with the xdg-desktop-portal-gtk.service running.

Cheers, John

[YaLTeR]

I'm wondering if ext-idle-notify and idle-inhibit Wayland protocols include zwp_idle_inhibit_manager_v1 :

Yes, this is idle-inhibit. But it requires a surface visible on screen to inhibit idle. SwayAudioIdleInhibit seems to just create a surface and do nothing with it as far as I can tell: https://github.com/ErikReider/SwayAudioIdleInhibit/blob/e660559718913c1e3d3aadf03f2986ed687d4fb9/src/idle.cpp#L50

The protocol says:

If the surface is destroyed, unmapped, becomes occluded, loses visibility, or otherwise becomes not visually relevant for the user, the idle inhibitor will not be honored by the compositor

And if you do nothing with the surface then it's unmapped, meaning that the idle inhibitor is not active. So I'm not sure why it works on sway, maybe a sway bug.

One thing you could try is to call org.freedesktop.ScreenSaver Inhibit via D-Bus. I don't think it requires an open window, but it does require the process that called D-Bus to stay alive (as soon as it dies, the idle inhibit will stop).

[plum]

@YaLTeR Thanks, for your information is what I needed to know, in order to begin to understand what is (not) happening.

I could try your tip out, by calling org.freedesktop.ScreenSaver Inhibit via D-Bus. BUt in order to work more usefully than than the existing waybar inhibit idle toggle, I imagine I eould have try to initiate it with a script that detects audio playing from source or to sink I think. AM I right?
I may be able to do that, I'm not yet sure if I have or could find, existing script resources to learn and work from. I should look into that, perhaps.

[YaLTeR]

I imagine I eould have try to initiate it with a script that detects audio playing from source or to sink I think. AM I right?

Sounds about right

[algernon]

Perhaps my ala-lape tool can be of use here? Its purpose is to inhibit idle when certain conditions apply, and it does so through systemd, rather than any wayland protocols, because I found this method to work much more reliably.

It can currently detect gamepad input and configured processes, but I suspect it wouldn't be too hard to teach it to monitor pipewire either. I'll see what I can do.

[plum]

@algernon Thanks for kind suggestion, and offer to look into extendng your script to include active pipewire sinks or sources. You might glean the information you need from swayidle, as you possibly intend to, which does preceisely that, or perhaps wayland-pipewire-audio-idle-inhibit would be a clearer example to follow.

I looked at ala-lape README and docs. It certainly looks like a script that is purposeful and for good reason.
You say in the docs for ala-lape (an intriguing name!) THAT,

"The logind inhibitor will inhibit idle via systemd-inhibit(1)'s DBus interface";

Does 'logind inhibitor' of the ala-lape script only work to inhibit systemd suspend services? OR, would it also block something like a running swayidle daemon's timeout suspend commands?

My understanding is, and as I have consistently found to be true, that logind services' suspend options will not suspend in either Niri sessions, or when runnning Niri as a 'non-session' window manager, which is to be expected when running wayland because logind has 'no idea' whether such windows are idle or not, and hence the need of use of a second level daemon like swayidle to issue suspend commands.

PS. Upon reflection, you rsolution might be the solution in progress that many people have been looking for some time, and if successful could find their way to it to considerably enhance the wayland experience.

[algernon]

Does 'logind inhibitor' of the ala-lape script only work to inhibit systemd suspend services? OR, would it also block something like a running swayidle daemon's timeout suspend commands?

In my experience, it also blocks swayidle. I have a systemd service for swayidle that runs swayidle -w timeout 600 <my-lock-script> (where <my-lock-script> pauses music players, turns off the screen, and calls swaylock), and when ala-lape does its thing, swayidle doesn't trigger either.

Anything that takes systemd's idle inhibit state into account should play well with ala-lape.

(It's also reasonably easy to extend the tool to support other ways of pausing idle inhibition, like it has optional support for inhibiting notifications too, for some of the notification daemons out there.)

[algernon]

Just had a look at the pipewire-rs API docs, and damn. That's a bit complicated. Nevertheless, I know how to add sink & source monitoring to ala-lape, I just need to stock up on sanity points before I dive into the implementation. Might take a couple of days.

[plum]

@algernon Hello There Gergeley. KInd of you to do so. Yes, dont tire yourself now, gain those sanity points now after breaking through that tough reading! It's time to finish Christmas preperations and enjoy peace over the season.

Sorry about my delay in reply; I either missed yours buried in the threaded email posts, or it came late.

When you get round to fnishing off the extension to ala-lape then, I hope it goes easily and delightfully for you. I'll be keen to give it a go!
All good wishes to all Niri users and your family at Christmas time, and into the new Year. John