Re: Unexpected quasi-pause when switching desktops

The Wanderer <[email protected]> Mon, 29 Aug 2022 10:25:07 -0400
Newsgroups	gmane.comp.video.mplayer.user
Organization	This space intentionally left blank.
Message-ID	<[email protected]>
On 2022-08-29 at 10:04, Reimar Döffinger wrote:

> Hi! it seems my email got lost, so sending again, sorry for the
> quoting that got a bit messed up because of that:

No worries; thanks for responding.

>>> On 27 Aug 2022, at 03:38, The Wanderer <[email protected]>
>>> wrote:
>>> 
>>> I've run a few of these tests now, and the results look
>>> interesting, but I'm not sure what they mean.
>>> 
>>> With -vo gl and -ao alsa, the problem happens in what appears to
>>> be the exact same way.
>>> 
>>> With -vo x11 and -ao alsa, the problem does *not* happen.
>> 
>> Sounds like either windows on the other desktop are not getting
>> access to the GPU at all, or vsync is broken. Could try -vo
>> gl:swapinterval=0 but if you use a compositor it might be its
>> fault/breaking itself.

I don't, but if I'm not mistaken, the last time I tried this (leaving a
video window playing on another desktop) was before switching to a new
GPU and making several major software upgrades - so it's entirely
plausible that part of the underlying rendering stack has changed its
behavior.

I'll try the suggested option and see if it affects anything, but not
right now.

Honestly, the main reason I use -vo vdpau (and -vo gl, before it) is
that without that I used to get lagginess when scaling videos to my
display resolution for fullscreen playback - both scaling up and,
possibly even more so, when scaling down. But I have a more powerful CPU
now than when I remember last encountering that symptom, so maybe it
might be worth switching back to -vo x11 and forgetting about the
problem, at least in the short term.

>>> =====  PAUSE  =====
>>> [AO_ALSA] pcm pause error: File descriptor in bad state
>>> [AO_ALSA] pcm resume error: File descriptor in bad state
>>> 
>> 
>> I am guessing the vo slowing things down that much then breaks the
>> ao, making the issue more "sticky".
>> Another option might be to use "perf" with wall clock time sampling
>> figure out where exactly things get stuck, but I don't know how to
>> do that out of my head.
>> But it seems a video/GPU issue.

I tend to concur.

>> I don't think much changed in MPlayer, so if it's a regression I'd
>> think compositor/window manager/GPU driver to be a more likely
>> cause than MPlayer to be honest...

Seems likely, yes. Doesn't rule out the possibility of being able to
find a way to change MPlayer to correct for it, but having landed on the
idea that the rest of the system is deciding that something not
currently being displayed doesn't get GPU resources, that possibility
doesn't seem terribly likely to be worth investing any effort into.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

_______________________________________________
MPlayer-users mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
signature.asc (application/pgp-signature, 833 B)