Bug 64069

Summary:	while playing mp3s or ogg files the player will stop and report could not open audio
Product:	[Fedora] Fedora	Reporter:	Xander D Harkness <harkness>
Component:	xmms	Assignee:	Colin Walters <walters>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	ajschult784, chris.ricker, nobody, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-22 06:00:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Xander D Harkness 2002-04-25 01:08:46 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020409

Description of problem:
Xmms while running in KDE or gnome will stop while changing to a new track
(playing either mp3s or oggs) and report could not open audio.

It is often on the same tracks.

When opening xmms from the console window I get the following reported at the
console:

esd: Esound sound daemon already running or stale UNIX socket
/tmp/.esd/socket
This socket already exists indicating esd is already running.
Exiting...

If I click the play button play continues for a few tracks until a similar event.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1.Play a series of mp3s or oggs either at random or in sequence
2.A dialog window will appear to advise that Xmms could not open audio.
3.click play to continue
	

Actual Results:  As described

Expected Results:  Play should continue through the list 

Additional info:

Comment 1 Warren Togami 2002-04-28 04:10:44 UTC

When you are in KDE, set xmms to use aRts for sound output. 
When in Gnome, you should set it for esd sound output. 
 
Does the problem exist in both cases with these settings?

Comment 2 Andrew Schultz 2002-05-14 00:12:54 UTC

I'm seeing the same thing.  xmms is using esd and I'm running blackbox as my WM.
I get no message in the console.

I saw this with 1.2.7 rawhide under RH7.2 and now RH7.3.

Comment 3 Xander D Harkness 2002-05-14 04:14:26 UTC

I cannot test Xmms using aRts in Linux as there is a separate bug which causes
Xmms to crash instantly. (this is already listed on Bugzilla)

I also get this error on RedHat 7.2

Comment 4 Warren Togami 2002-05-14 04:40:40 UTC

If you erase the file(s) in ~/.xmms are you able to run XMMS?

Comment 5 Andrew Schultz 2002-05-14 13:23:47 UTC

I nuked ~/.xmms and still see the same problem.

Comment 6 Bill Nottingham 2002-12-11 21:55:26 UTC

*** Bug 79372 has been marked as a duplicate of this bug. ***

Comment 7 Chris Ricker 2003-02-20 05:34:59 UTC

still see this with latest phoebe beta

Comment 8 Bill Nottingham 2004-01-29 04:19:15 UTC

*** Bug 53123 has been marked as a duplicate of this bug. ***

Comment 9 Warren Togami 2004-01-29 06:00:59 UTC

I see this with only certain kernels on my laptop.  I am guessing that
xmms is releasing control of the audio device momentarily between
songs, and during that instant the device is ungrabbable.  This only
happens rarely and only during times of medium/high CPU usage.

xmms I am hearing might be removed from Core in a future release
because it is being replaced by newer software like rhythmbox.  RH is
unlikely to have the resources to look at this problem that seems to
be dependent on audio driver behavior/response time or a xmms problem
itself.  If you want this fix it would be best to talk to xmms
upstream developers.

Comment 10 Xander D Harkness 2004-01-29 08:36:22 UTC

This is very different from the behaviour that I see.  May be I should
have been more clear.

The average load on the system is 0

The halt happens on a song change, when xmms moves from one ogg to
another.  It decides it does not like this ogg and stops.  This is an
ogg that other versions of xmms and ogg123 will happily play.

Comment 11 Colin Walters 2004-09-22 02:18:33 UTC

Can you narrow this down to particular files?

Comment 12 Andrew Schultz 2004-09-22 05:44:07 UTC

Colin: it has nothing to do with the files.  at high system load, xmms
tries to get ahold of esd and it takes too long and tries again (or
esd thinks it's not active and starts up, or something -- I figured it
out at one point) and then it discovers too late that it's already
active and fails.  The problem doesn't happen with the alsa driver. 
esd itself switched to using alsa (with FC2) and the problem has not
been so bad since then, although it does still occur.

Comment 13 Colin Walters 2004-09-22 06:00:41 UTC

Looks like this bug:
http://bugs.xmms.org/show_bug.cgi?id=1673