Red Hat Bugzilla – Bug 196583
xmms stops during high system load and doesn't resume
Last modified: 2008-05-06 12:03:01 EDT
Description of problem: When my machine (fully updated FC5) reaches a "high" load (3 or more) and I'm playing my music with xmms the music playing often stops. Now, it did so too with FC3, but then it always resumed playing when the load returned to a more normal level. Now it doesn't. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. launch xmms 2. start increasing load (start compiling glibc and the kernel at the same time or so) 3. Actual results: music playing stopped and didn't resume after load had returned to normal. Expected results: music should have continued Additional info: I am using the xmms-mp3 plugin from Livna.
I think I have experienced the same occasionally, but unfortunately don't have a clue where to look for the culprit. WAG: have you tried with different output plugins if possible in your setup to see if it makes any difference? (I assume you're using the ALSA output plugin.)
I've altered OSS and ALSA. I have not experienced it with OSS at all, and sometimes with ALSA (even after I added an addition 1 GB of mmeory). It is impossible to reproduce on demand though :(
On FC6 this is still present. I'm untarring a disk backup now and with the ALSA output plugin it keeps on hanging repeatedly.
I can confirm the presence of this problem also on FC5 and FC6. I just had it show up on a newly installed, fully updated installation of FC6 on a Dell Latitude D600 which had the same problem on FC5. Like with Armijn, happened with ALSA, hasn't yet happened with OSS. Comment number 4 from Luis in bug #118340 seems to be talking about this same problem, though that bug isn't the same in whole.
Well, actually it is how I resume playback as well once it hangs and I think that comment should have been here :) (the bug in general is indeed different to this one) I never ran FC4, so I can't say if it already started there, but it could very well be.
I'm unable to get playback to stop at the moment due to artificially caused high load (got up to 7+ but it just kept on working just fine). However, one way to easily trigger a possibly related no-resume condition is to start playing something, then background xmms with Ctrl-Z in the console, then foreground it again with "fg". With OSS playback continues here when foregrounded, with ALSA not. Updating the ALSA output plugin to current upstream CVS HEAD appears to fix that here. Perhaps it fixes the no-resume-after-stopping-due-load problem too? Please rebuild this source rpm and install the resulting binaries and report back how it looks: http://cachalot.mine.nu/tmp/xmms-1.2.10-30.src.rpm
I've done some I/O which would usually stop XMMS and have not experienced it yet with this version. I think it is a bit too early to close the bug, but there is progress it seems :)
Hm, it seems I cried victory too soon, it just happened again.
I have experienced the same problem. But with FC5 and FC6. I never had this problem with FC4
From what I've seen, when the processor is really getting hammered, the buffering doesn't get refilled, but as soon as things relax a bit, everything returns to normal. This behaviour has been the same since FC5. It looks to be a buffer problem. Can you disable ALL plugins except OGG (or mp3), use ALSA and see what happens when you hammer the processor?
Created attachment 145501 [details] Handle xruns properly in alsa plugin Check for status after snd_pcm_mmap_commit needed because it does not return errors as expected (at least with alsa-lib 1.0.13).
Looks like with alsa-lib-1.0.13 xmms stalls in snd_pcm_status(). 1.0.14rc1 seems to do the same, too.
(In reply to comment #4) > I can confirm the presence of this problem also on FC5 and FC6. I just had it > show up on a newly installed, fully updated installation of FC6 on a Dell > Latitude D600 which had the same problem on FC5. This problem is still alive, I've now occasionally also experienced this problem on a Fedora 7 system (xmms-1.2.10-36.fc7), where the load has not been specially high (since it is a dual dualcore Xeon 3.0MHz system). Unable to try switching xmms to use OSS, as this fails with: oss_open(): Failed to open audio device (/dev/dsp): Device or resource busy
Though I also see this in Fedora 7, I'm *not* seeing it in audacious-1.3.2-1.fc7. I'm told that xmms is no longer actively maintained, and audacious seems to be an active successor.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.