> I disagree that the bsd audio driver was optimized for interactive
> performance at the expense of simplex playback performance.  We made
> it block- rather than stream-oriented because doing things in chunks
> is more efficient than a byte at a time and using fixed size chunks
> makes the implementation simpler.  The block size is configurable,
> so you can make it big for playback applications.  If you don't
> like the default of 160, have the playback application set it
> or patch it with kgdb.  Alternatively, we can create the equivalent
> of /dev/audioctl and make a configuration utility.

There are some problems though. Especially where a write fragment is 
less than a block and you need to fill the rest with silence. This
can add gaps to the playback. It would be nice to fill them with silence
but overwrite the fill with audio iff the black hasn't been given to the
DMA.

The blocksize is also calculated based on channels, data-size, and rate.

BTW- there is now a /dev/audioctl interface.

> 
> I'll agree that the current workaround for half-duplex operation
> is half baked.  I'm not sure how easy it would be to re-do audio.c
> so it can handle both simplex and full-duplex cards in a uniform way.
I hope to be able to experiment with full-duplex audio on the PSS card
soon. Until then tuning the half-duplex code is about the best that
can be done at the moment.

> 
> Do we really need 64K buffers?  Have you measured the cost of
> the system call versus the copy?  My guess is that one page is
> enough to amortize things.  I suppose scheduling contention could
> cause problems (1K at 8Khz is 128ms).

So far at 44.1khz 16bit stereo, small buffers are a big lose. I've gotten
some bigger buffers (64k) and I'm now trying to optimize the blocking
code for this. If you use a big blocksize (8k), then the silence fragments
really hurt.

Also what is the intent of the "scheduling backlog" ? I'd like to have
another sort of backlog - fill some percentage of available buffer space
and then start DMA.

Something else that I'm considering is to move the select and sleep wakeups
out of the hardware interrupt processing and create an audio softisr for
it (like on the Sparc). My thoughts are to minimize the code in the DMA
engine to reduce/eliminate clicks and pops.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 John Brezak                    UUCP:     uunet!apollo.hp!brezak
 Hewlett Packard/Apollo         Internet: brezak@ch.hp.com
 300 Apollo Drive               Phone:    (508) 436-4915
 Chelmsford, Massachusetts      Fax:      (508) 436-5140