Re: esound eats CPU cycles

[Andrew Clausen <clausen alphalink com au>]

Ronald de Man wrote:

> > 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).

I remember when reading the creative-docs, that the "high" DMA channels
(4-7) are much faster than the "low" ones (0-3).  But when you do full
duplex mode (16-bit), then you'd need the two channels (including the slow
one at the high rate)

When you do a DMA transfer, doesn't it lock up the bus?  While your CPU is
in parrallel, I think it needs to wait for the DMA for memory access (I
could be wrong on that...it might only be for <=486 motherboards, I've got
no idea...)  If the DMA is taking a long time, then its effectively taking
away CPU time (if what I said above is true).

Another option would be to try doing 8-bit DMA with esound - see if that is
any better.  That would halve the time for the DMA, halving the CPU time it
eats (again, if what I said is true)

Andrew Clausen