dev/sound patches to reduce latency

[Mathew Kanner]

On Apr 22, Luigi Rizzo wrote:
> attached are some patches for the sound driver to reduce latency
> in the playback channel.
> Background - by design, the driver tries to keep the "hard" buffer
> (the one used by the hardware to play samples out) always full
> even if userland supplied a small amount of data. While there is
> an ioctl() to set the size of the buffer in terms of a blocksize
> and number of blocks, the existing code failed in some cases to
> push down the info to the hardware, and had the tendency to
> use max-sized buffers in many cases. At 8khz, the 16k default buffers
> could cause very large delays in the playback of audio.
> 
> With this patches, we try to pass the user-specified blocksize down
> to the hardware, and furthermore, use a small number of blocks in
> the "hard" buffer to minimize latency.
> 
> I'd appreciate if people could test this code and report any good
> or bad news. I think it significantly improves what we have now.
> It could still benefit from an additional improvement:
>   - make the choice of the number of buffers adaptive on the irq rate.
> which is not a very complex thing to do, but should be done in all
> individual drivers, so it takes a bit more testing.

	Hi Luigi,
	I've started to look at your patches by brining them up to
6.x.  Integreating them is been hard because the 4.x code base does
not have the (heroic) changes that truckman commited about a year ago
that cleans up/changes the sound buffer.  I'm not done yet, but I
wanted to stop and ask:  Have you tried 5-+?  It should be a little
better in regards to buffer allocation.
	--Mat