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):
Steps to Reproduce:
1. launch xmms
2. start increasing load (start compiling glibc and the kernel at the same time
music playing stopped and didn't resume after load had returned to normal.
music should have continued
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
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
I never ran FC4, so I can't say if it already started there, but it could very
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.
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
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:
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.