Indeed Matthew, *muting* happens as a consequence of *pausing*. I've tried in a FreeBSD 10.1 amd64 machine and exactly the same things happens. Hence, it must be related to X.org rather than to OpenBSD.
No big deal, I certainly can live with that. Regards, Luciano. On 19 January 2016 at 13:03, Birger Andersson <b...@vivaldi.net> wrote: > Hi Matthew > > Good point. Sound is muted and indeed playback is paused. Maybe it's the > pause that cause the muting. > > On further investigation in xfce, under the condition that the checkboxes > 'Hide content of > windows [when moving] or [when resizing]' are ticked muting and pausing > occurs when windows are moved/resized using mouse or keyboard. > > Furthermore, moving/resizing when using smplayer for playing a video file > results in a mute and pause. Playing an audio only file results in no mute > or pause. Window wise there is no canvas area but only the window > decorations when playing the audio file. > > Using mplayer from a terminal window and moving/resizing any window then > both the video file and the audio file gets muted and paused. > > /birger > > > On 2016-01-19 13:50, cho...@jtan.com wrote: > >> Luciano Rottava da Silva writes: >> >>> Hello, >>> >>> Same here with fvwm2-2.6.5 (installed via pkg) and 5.8-release. >>> >>> But in my case it happens when moving or *resizing* any window (xterm, >>> firefox, etc.) if I keep mouse pressed doing any of above event "long >>> enough". >>> >>> Looks like this issue is not directly related to wm or desktop >>> environment. >>> >> >> Are you sure it's *muting* and not *pausing*? >> >> ISTR from back when I used fvwm that this behaviour was caused by mouse >> drags freezing communication with X, causing all X clients to pause >> until the mouse dropped. >> >> I didn't ever fix it, sadly. Being one of those things that Shouldn't >> Even Be Possible I just chalked it down to X being X, where that >> statement is invalid. >> >> This was not on OpenBSD, by the way, but I doubt that matters. >> >> Matthew
