Bug 196583 - xmms stops during high system load and doesn't resume
xmms stops during high system load and doesn't resume
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xmms (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul F. Johnson
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-25 06:18 EDT by Armijn Hemel
Modified: 2008-05-06 12:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:03:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Handle xruns properly in alsa plugin (2.07 KB, patch)
2007-01-12 18:42 EST, Sami Farin
no flags Details | Diff

  None (edit)
Description Armijn Hemel 2006-06-25 06:18:12 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.
Comment 1 Ville Skyttä 2006-07-05 16:13:45 EDT
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.)
Comment 2 Armijn Hemel 2006-07-17 06:08:04 EDT
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 :(
Comment 3 Armijn Hemel 2006-11-05 13:48:58 EST
On FC6 this is still present. I'm untarring a disk backup now and with the ALSA
output plugin it keeps on hanging repeatedly.
Comment 4 Otto J. Makela 2006-11-16 19:35:32 EST
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.
Comment 5 Armijn Hemel 2006-11-16 19:44:28 EST
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.
Comment 6 Ville Skyttä 2006-11-18 06:33:33 EST
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
Comment 7 Armijn Hemel 2006-11-19 11:38:55 EST
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 :)
Comment 8 Armijn Hemel 2006-11-19 11:56:32 EST
Hm, it seems I cried victory too soon, it just happened again.
Comment 9 pritam ghanghas 2006-11-27 07:33:47 EST
I have experienced the same problem. But with FC5 and FC6. I never had this
problem with FC4
Comment 10 Paul F. Johnson 2007-01-02 19:03:12 EST
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?
Comment 11 Sami Farin 2007-01-12 18:42:27 EST
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).
Comment 12 Sami Farin 2007-01-13 09:21:06 EST
Looks like with alsa-lib-1.0.13 xmms stalls in snd_pcm_status().
1.0.14rc1 seems to do the same, too.
Comment 13 Otto J. Makela 2007-07-23 20:03:55 EDT
(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
Comment 14 Christopher Beland 2007-09-13 12:43:30 EDT
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.
Comment 15 Bug Zapper 2008-04-03 23:09:56 EDT
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
Comment 16 Bug Zapper 2008-05-06 12:02:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.