Re: esound eats CPU cycles

[deman win tue nl (Ronald de Man)]

> > Ronald de Man writes:
> >  > I have the lastest version from CVS. No sound is playing, just
> >  > esd running in the background. Esd should be sleeping, and strace
> >  > shows that it is. But the performance decrease is real.
> > 
> > Might you have slow DMA on your combination of motherboard and sound
> > card?  Nearly all sound cards use DMA to transfer data, and I would be 
> > very surprised if esd closed the sound device -- starting and stopping 
> > the DMA often produces a click.  The device driver
> > 
> > Stop esd and try this:   dd if=/dev/zero of=/dev/dsp bs=8k count=20
> > 
> > I'll bet it clicks.  It does on mine.  While it's running, do your
> > gzip test.  On my system it doesn't show any performance decrease.
> > Does it on yours?
> 
> I'll try when I get home. This seems to be a very reasonable explanation.
> My sound card is an SB16 without 16-bit DMA. I can play 16-bit sound
> by setting the 16-bit channel equal to the 8-bit channel. I don't
> know why this works but it does, and it is probably the reason of
> the slow down. The computer shop where I bought the card is even
> more crap than the card (Creative ViBRA 16X PnP).

Just tried it and this test did NOT give me any performance decrease.
Maybe I've been too harsh on my sound card :)

Next I've been playing with gdb and I think I found something interesting.
If I put a breakpoint at audio_oss.c:128 (the return in esd_audio_pause()),
and run esd I do get a slowdown (with esd being stopped at that line).
If instead I put a breakpoint at audio_oss.c:127, run esd, and continue
after it has encountered the breakpoint, I do not get a slowdown and now
esd is running.

So it seems to be some subtle timing problem. Might be my sound card or
hardware, might be 2.0.36. I'll now try an old kernel.

Ronald