Bug 37078

Summary: component using esd halts
Product: [Retired] Red Hat Linux Reporter: Zeeshan Ali <programmer>
Component: esoundAssignee: Elliot Lee <sopwith>
Status: CLOSED WORKSFORME QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.2CC: emitchell
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-26 20:17:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Zeeshan Ali 2001-04-22 17:29:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)


I am using Red Hat Linux 6.2 & 7.0 on varrious intell compatible but 
different plateforms. Any application using EsounD halts after some time 
including GNOME itself. The time it takes varries much. 

Reproducible: Always
Steps to Reproduce:
using xmms or
enabling sound events in GNOME

	

Actual Results:  After some time any of those application completely 
halts, killing them may help, but the esd could possible be killed by the 
kill command.

Expected Results:  I should have enjoyed great music out of it.

Comment 1 Elliot Lee 2001-04-29 17:58:27 UTC
Given that noone else has experienced this problem that I know of, how can I
reproduce this on a clean install of stock RHL 7.0?

Does the problem occur only on machines with a particular sound card?
What is the minimum/median/mean/maximum time delay before these applications
start dying?

Comment 2 Zeeshan Ali 2001-04-30 08:46:16 UTC
Not some specific soundcard. I have got a CMM18330 & i have recently tested 
this behavious on some other soundcards( by intel ). I have tried it on some 
completelly different machines( only intel compatilble ). The time it takes to 
halt depends heavilly on the load on CPU. However if i sit back & only xmms is 
running, then it halts after some 15-20 mins.

Comment 3 Zeeshan Ali 2001-05-08 18:02:09 UTC
I have come to know by experience that i get this problem when gnome( or X ) is 
running. I have a Cirex M-II 333Mhz with 64MB RAM( 4 MB shared with Video 
card ). I enjoyed great quality MP3 songs out of mpg123( a cammand line MP3 
player that uses esd ) when i used it daily for 2 weeks without any GNOME( or 
even X ) running. Only yesterday did it got hung when i started to work on 
gnome in parallel.

Comment 4 Zeeshan Ali 2001-05-10 17:22:56 UTC
Problem Reduced: Making the esd run explicitly( by 'esd &' ), before GNOME does 
on startup, greatly reduces the problem. The applications still halts but for 
only a sec.( or less ) on playing each sound. I have further observed that a 
portion of beginning of every sound is not played untill & unless another sound 
being play is in progress. E.g When I do 'esdplay /.../gnobots2/yahoo.wav', i 
only hear some silence followed by 'yoo'. Repeating this after the sound is 
played gives the same result. But if i repeat it before the first 'hoo' sound 
is being played, i hear the complete sound & so on.

Comment 5 Elliot Lee 2001-08-26 20:17:53 UTC
Not that I have been doing my best to find a solution (sorry for the delay), but
I hate to leave bugs just sitting around when no reproduction is possible.
'esdplay /usr/share/sndconfig/sample.au' is what I use for my "does esd work at
all" tests - no halting or truncation here. I need a test case that will produce
the problem for me - right now I just want to blame very slow hardware or
something, although that is just a wild guess.

Comment 6 Zeeshan Ali 2001-08-26 20:50:10 UTC
Yes, your gues is right. I upgraded my system & i dont get this error any more. 
But i would really like the system requirements for GNOME &/or esd explicitly 
mentioned on their official websites.

Comment 7 Elliot Lee 2001-08-26 20:56:25 UTC
Well, the main problem with hardware requirements is that it should all work
properly with your previous hardware as far as I know. It really just takes
effort by a knowledgeable person who has access to a system where the problem is
occurring.

Thanks for your patience.