mplayer vlc kaffeine all players hang/pause when I switch away from the VT they use (to other desktop or terminal)

[Bug Hunter]

When I play video in any player which I tried - mplayer, vlc, kaffeine, totem,
they all "hang" when I switch to other VT.
While I'm on another VT (say vt-1 konsole, or vt-9 desktop 2) then no sounds is playing.
If I switch back, then player behaves as if it was hanging all the time - it "chokes", jumps to the position that should be playing now, shows jumpy video for a moment, and then continues normally.

ii xserver-xorg 1:7.3+10ubuntu10.2
ii xorg 1:7.3+10ubuntu10.2
ii xserver-xorg-input-all 1:7.3+10ubuntu10.2
ii xserver-xorg-video-all 1:7.3+10ubuntu10.2

ii nvidia-glx-dev-envy 1:96.43.05+2.6.24.503-503.30
ii nvidia-glx-envy 1:96.43.05+2.6.24.503-503.30
ii nvidia-kernel-common 20051028+1ubuntu8
ii nvidia-kernel-source-envy 1:96.43.05+2.6.24.503-503.30

 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux

[Bug Hunter (bughunterlinux)]

I tried strace, but I was yet not able to find any abnormal behaviour visible via strace when I switch to VT and back.

I tried gdb, and it did showed following.

Each time I stoped program in gdb to show it current bt, it was in select(), both when normally working and while hanging (when on other VT).

Only thing so far I noticed is that while in other VT, then atop cpu usage kaffeine=3% pulseaudio=~0%, and in same VT kaffeine=6% pulseaudio=5%

All the above is on geforce 2 mx gfxcard;

Section "Device"
    Identifier "Device0"
    Driver "nvidia"
# VendorName "NVIDIA Corporation"
EndSection

#0 0xb7f9e410 in __kernel_vsyscall ()
#1 0xb63aa881 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb6a930e3 in QEventLoop::processEvents (this=0x81c9eb0, flags=4)
    at kernel/qeventloop_x11.cpp:294
#3 0xb6b08f90 in QEventLoop::enterLoop (this=0x81c9eb0)
    at kernel/qeventloop.cpp:201
#4 0xb6b08c8e in QEventLoop::exec (this=0x81c9eb0)
    at kernel/qeventloop.cpp:148
#5 0xb6aef7df in QApplication::exec (this=0xbfce3140)
    at kernel/qapplication.cpp:2761
#6 0x08075f40 in main (argc=22904, argv=0x0)
    at /build/buildd/kaffeine-0.8.6/./kaffeine/src/main.cpp:120

[Bug Hunter (bughunterlinux)]

Using driver "nv" instead "nvidia" changes nothing.

Playing with mplayer -vo aa do not help - still when going to VT-1 it stops

But when in say VT-3 (text console) I start mplayer -vo aa, then its all ok - switching to any other VT (text and X) do NOT stop playback - yeeey.

Turning off kaffeine option [ ] stop playback when window is not visible does not help

[Bryce Harrington (bryce)]

Hi bughunterlinux,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[Shentino (shentino)]

Reopening this bug because I have new information to report, and also because I was recently a victim of the bug at least with the latest Jaunty.

I also seem to run into trouble with sox playing stuff on a bare VT and switching away from that...same symptoms.

One factor I've noticed is that if the target and source VTs have different owners, i.e., different users are logged in to each, then the sound suspends.

[Shentino (shentino)]

So, since it also happens even when X isn't running it might not be an xorg issue after all. Even sticking purely to text-mode VTs it happens.

[Shentino (shentino)]

Changed package away from xorg as it doesn't seem to be an xorg issue

[Shentino (shentino)]

Update:

Confirmed in karmic.

on tty1:

$ play some-music.flac

(plays)

(switch to VT 2)

(music dies)

(switch to Vt 7 desktop when user logged in is same as on VT 1)

(music continues)

It seems a reliable factor that the current console needs to be owned by whoever owns the VT the sound is coming from.

[Shentino (shentino)]

Just noticed something new.

Even when the origin and target VTs during a C-A-F# vt-switch are owned appropriately, there's a skip.

Rapid switching between VT1 and VT2 cause hellish skips even outside of X when using nothing but console to play music.

Xorg is DEFINITELY not at fault here. Even sound playing on VT1 is getting glitched just by switching to another VT, and it doesn't even have to be the one running X.

Why VT to VT switching is even messing up the sound at all is alarming.

My guess is that during the VT switch sound is being suspended while the system checks ownership of the target VT, and by the time it clears, the buffer has already emptied.

Well, my opinion is that if you're validly logged into one VT, leave the sound alone. VT switching should not mess with the sound PERIOD.

What should be happening is that all the sound stuff is happening in the background and the system needs to darn well leave it alone when VT switching.