start xmms, import both an mp3 and ogg into xmms. Play ogg -- then click-hold and drag the window around the desktop while ogg is playing -- this, on my system, and another whom I've talked to, pauses the xmms ogg ouput. This does not happen with mp3s. Therefore I suspect it has something to do with the cpu cycles involved and libogg (but this is mere speculation - I have no hard data to back this up.) This does not happen when you scroll in a window of any type (tried in web-browser and in xterm). The only time (that I've found so far), that this happens is when doing the above. NOTE: this is xmms 'pausing' output, not just un-heard audio, as xmms will resume playing where it paused the ogg once you release the window. Reproducible: Always Steps to Reproduce: 1. Start xmms 2. Load both an ogg and mp3 file 3. Play ogg file 4. Click-hold and drag a window around the desktop for > 2 seconds -- xmms will pause ogg output. 5. Play mp3 file -- do same from #4 -- xmms does not pause output. Actual Results: XMMS ogg output paused -- stream was somehow interrupted. Expected Results: Should keep playing output. Perhaps a renicing of xmms is in order, but this will not fix the problem for the 'average' non-root user. Programs I had running: Multiple x-terms Epiphany Xchat2 Hardware information: Linux horkinfiberchunks 2.4.20-gentoo-r5 #1 Sun Jun 1 23:16:45 EDT 2003 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux lspci output 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:0e.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 1b) 00:11.3 USB Controller: VIA Technologies, Inc. USB (rev 1b) 00:11.4 USB Controller: VIA Technologies, Inc. USB (rev 1b) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 70) 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4800] (rev a1) Kernel Option information: Pre-emption is enabled -- bigmem is not Sources: gentoo-sources Memory information: Mem: 902792 892504 10288 0 175808 413888 Software versions: XMMS: media-sound/xmms-1.2.7-r20 libvorbis: media-libs/libvorbis-1.0-r2 libogg: media-libs/libogg-1.0 Per top: xmms has a nice value of 0 Any other information that may be important, please let me know, and I will reproduce environment and try to capture necessary data. I considered this a 'major' severity, as there is something wrong with a default xmms plugin:
I forgot to add to my original post, that I fiddled with the ogg player plug in buffer sizes and pre-load percentages under the configuration tab -- upped it to 2048 k buffer (and variations thereof), and 90% preload (and variations thereof), with no success. XMMS ogg plugin is version 1.2.7 (libvorbis.so) Also, my CFLAGS="march=athlon-xp -O2 -pipe" Can't think of anything else at the moment Regards
Another note: Ran ogg123 <file.ogg> as a regular user, and did the methods mentioned above -- the problem does NOT exist with ogg123. So it must, I assume, be related to the xmms ogg plugin. Extra data: Top output with ogg123: 32250 foo 15 0 2092 2088 1444 S 1.3 0.2 0:00.35 ogg123 32252 foo 15 0 2092 2088 1444 R 0.7 0.2 0:00.12 ogg123 note the nice values above -- 15 versus 0 for xmms, which really makes no sense. CPU usage is, however, higher with ogg123 as opposed to xmms -- but the problem is non-existant -- there is no pausing of output while dragging windows around. note also, not sure how pertinent this is, but the ogg123 buffer was always 96.9% full during playback. Also note, I have used the same .ogg/mp3 tracks for all this testing. Regards,
I know this may not be of direct help to tracking down the problem, but I tested under windowmaker and kde and had no problems playing an ogg file (in xmms) but when I used fluxbox and played the same ogg file in xmms and tried moving the windows as above I experienced the same problem. kinetik on #gentoo mentioned that his fluxbox version was 0.1.14* and was having the same difficulty, I am using fluxbox-0.9.3 so it is not version specific. Saying that it is simply a flux problem is yet to be shown though.
OK ive been doing some futher experimenting with both fluxbox version 0.1.* and 0.9.* and have seemingly come across an interesting issue. Using the ALSA output plugin 0.9.* stalls instantly when moving the window, but when you try to move the window again straight after everything works fine. 0.1.* stalls instantly irrespective. Using esound 0.9.* Only the XMMS window does not get refreshed (ie the scope bars stop moving) but music will play continuously. 0.1.* Stalls after 5 or 6 seconds everytime Using OSS 0.9.* Could not test (not setup of oss) 0.1.* Same as esound Using Artsd No problems with either (probably because this was done under KDE) The window refresh is obiviously a flux issue, but the sound output is seemingly something larger possibly fluxbox freezing all processes until the window redraw is complete. Not sure though... and that would be rather silly. Will look into it more later...
An additional note to the above -- this does happen with liteamp as well. Apparently this IS a fluxbox issue -- not sure what, but it's very odd. Also note that when dragging a window, while using mplayer, the same effect is found. Somehow, dragging windows in flux causes all processes to be backgrounded? I dunno. Regards,
New information: cyfred on #gentoo, seems to have discovered the 'real' issue. And that issue seems to be with fluxbox and the X function LockDisplay. My initial assumptions are wrong. It seems that when focus is given to moving a window about, fluxbox calls the LockDisplay function, which leads to: 1) all output in other windows not in focus halting updates / refresh, 2) all ogg output from an X window device being halted as well. This still does not happen with mp3 files, so that is kind of a mystery. Cyfred is going to fiddle with fluxbox code and see if it can't temporarily be disabled for testing purposes. Regards,
never mind the above comment about it NOT happening with mp3. It happens with that manner of file as well -- I believe that once cyfred investigates the flux code more, he'll find the source of the issue. Regards,
OK this thing just escalated slightly. When fiberchunks noticed that mp3's were having the same issue in liteamp I tried emerging liteamp to duplicate that. Problem I couldn't. On an off shot I recompiled xmms and wouldnt you know it... Ogg file play back worked fine aswell. The primary difference appears to be that I (cyfred) use gcc 3.3 and fiberchunks is using 3.2.3 -- from what Ive seen looking through fluxbox / XFree code and from what we've (as a community) have seen with GCC 3.3 and its code _strictness_ as such I think what is happening along the line somewhere is that a macro has been defined in one compiler and that has changed the way X handles its locking. That cant be entirely the issue though, as a recompile of the player (in my case xmms) with GCC 3.3 resulted in normal operation. Tracking this through the source may actually be a little more difficult than expected. Seemingly though as it does only happen under fluxbox (unless someone else comes forward) it would be how fluxbox calls XMoveWindow which calls LockDisplay that is creating the biggest problem -- XTHREADS might be the best place to start looking I think.
to add another little interesting nugget to this discussion, someone on #gentoo asked me about this, and mentioned that, after compiling a kernel with preemption support, his xmms under gnome2 seemed to exhibit the same behavior. I asked to follow up here, and post additional comments. Hopefully that will happen -- I may try recompiling the kernel on my box with gcc 3.2.3 and no pre-emption, to check that out, and see if that has any merit (which it seems it very well might?) Regards,
this problem is *most likely* not specific to ogg files... debian has an open bug which relates to this type of problem... with no distinct answer... http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=71118 and on the xmms side... there were some people that had problems in conjunction with AC97 chipset audio drivers in earlier kernels but that's about the closest thing to your problem. I have tested mp3 and ogg files with both the alsa and oss output and I have not been able to recreate your problem. (Currently using WindowMaker) I wonder if this issue shows itself in blackbox as well as fluxbox? I'll test more and report what I find. NOTE: I am using a kernel with preempt enabled.
Additional info, and a workaround. If you enable the 'opaque window movement' item in the fluxbox config (from the root menu), this problem goes away (at least for me it does.) Also, it seems that this is inevitable (according to han on #fluxbox). Apparently it's not going to be fixed, as it isn't on fluxbox's list of bugs to fix, so i dunno what the solution will be (i.e. if it will ever work with transparent window movement). Anyway, here's the current list of bugs, if anyone's interested: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/fluxbox/fluxbox/BUGS Regards,
I've made the fluxbox devels aware of this and they say it will go on their TODO.
This is clearly not a Gentoo bug, and upstream has been made aware. Closing with WONTFIX.
