> I've had a closer look at the architecture independent audio driver. It's
> really nice, but unfortunatly experience has shown, it's too slow most of
> the time (on slow machines or when computing the sound data). (I've used it
> with my own code on a SparcStation 1 and with a Soundblaster Pro on an 
> i486DX/2 66.)
> 
> The way it currently works is, that the hardware audio driver gets a block 
> of samples and when it's done with that (e.g. when it gets a dma_done
> interrupt) it requests the next block from the independent audio driver.
> Now it has to receive that next block in the time it takes to play one
> sample ... not much time, especially when playing at 44kHz ;)
> 
> So, to improve performance, I'd suggest a way that the hardware driver
> can request the next block even when it's not yet done with the one it
> is currently using.
When would it request it and how ? The lower level driver could bypass the
"layering" and implement the ring-buffer checks and keep on going.

> 
> As this requires a quite big change in the interface, I'd like to know if
> a) such an implementation has a chance to make it into netbsd?
Sure...
> b) anybody has some idea how to do that?
Not yet.
> c) what to pay attention to, if I was implementing such an interface?

Here is a little information on the buffering strategy in the audio driver.
And might provide a little bit of context on this dicussion.

....
The idea is that once the playback is started, it will keep going with fixed
block sizes. It saves having to reprogram the card and DMA engine on each
interrupt for a new transfer size. You want to have a constant playback
rate.

It is mainly optimized for interactive audio applications, were you want
to have minimum latency. I had thought of silence filling fragments, but
holding the pointer and continue with the next write buffer. If the DMA
caught up, it would play the fragment+silence, if not it would get a complete
buffer. This caused problems with blocking and fragmentation.
I was spending too much time playing with this code and getting too confused.
I will probably look at it again once the other parts are complete.

The basic idea is to feed fixed sized (in sample time) blocks to the
playback engine. You keep them small for interactive applications at
least for 8kHZ. There is an ioctl to change the block size. I've used
this for audio applications to get around this.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 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