Re: esd eats 25% cpu?

[Ronald de Man <deman win tue nl>]

On Wed, Jan 27, 1999 at 04:26:27AM +0000, Yo 'Ric Dude wrote:
> 
> For the record, my SB 32 AWE PNP does not exhibit this problem.
> 
> If you could reconfigure esound with the --enable-debugging option,
> run "esd -vt", and see if it's stuck in a loop somewhere.  If so, 
> post the repeating section, and I'll see if i can find anything 
> suspicious going on.  For bonus points, instrument your code with
> some debugging printf's (or use the ESDBG_TRACE macro), and track
> down which condition is keeping it from pausing properly.

Hmmm... some weeks ago when I first mentioned this, strace showed
that esd saw in a select() call, which I guess indicates that it's
pausing properly. But I just ran esd again and now strace is giving
me lots of

select(5, [4], NULL, NULL, {0, 11000})  = 0 (Timeout)
accept(4, 0xbffff7e8, [16])             = -1 EAGAIN (Try again)

Looking through clients.c this seems to be intended, though.

The delay seems to be the same as before. In both cases I was/am
using esound from CVS. I have upgraded to the 2.2.0 kernel in the
meantime.

esd -vt gives no extra output at all except for the 'enabling trace
diagnostic info'.

The problem is not something really obvious in esd. Running esd
with -as to have it release the sound device after a period of
inactivity lets the delay disappear the moment the sound device
is released. But having /dev/dsp open is not enough for the delay
to exist. It's something weird. It is probably my system. Maybe
the motherboard (ASUS P55T2P4) or soundcard (Creative ViBRA 16X PnP),
or the combination.

I don't have any delays while playing wav files (not through esd).

Ronald