i810 audio fixes 1/2

[Paul Davis]

>The intermediate buffering is the issue.   It's not a real big issue
>now with only a single buffer but it will be when wine supports
>hardware accelerated secondary buffers. You don't want 32 or
>64 streams of data each going through multiple intermediate
>buffers for SRC, format, and volume changes.  The point of
>direct sound is to provide the application programmer enough
>information about and control over the hardware to ensure
>optimal performance if desired. Hiding the hardware with layers
>of plugins is not the optimal approach. Even Microsoft learned
>that lesson the hard way.  Alsa's approach of providing a
>consistent interface requardless of the amount of code or time
>or CPU resources used is great if that's what you want but they
>also need to provide a fast path to the hardware when that's
>desired. I know they are considering this but it is not a priority.

the extent to which you are right depends on the intended target.

for pro-audio/music software, you're wrong. the APIs used by these
programs do not and will not use the kinds of h/w features you
mention. ASIO, in particular, does not model this kind of h/w, and
there are very good reasons for that, "learned the hard way". Neither
does GSIF or CoreAudio, the other two main "serious" audio APIs used
by proaudio/music applications. we (i write this kind of stuff) don't
use h/w features like this because the h/w is crap and there is never
enough control over the algorithms. the reverbs found on audio
interfaces aren't generally even close to usable for music production.
and you can't use stuff like gain control because of the way the apps
are structured (they are already implementing mixers with at least as
much functionality as a high end mixing console).

for games and some consumer software, yes, its probably true that
using h/w facilities like this is desirable.

there has been quite a bit of discussion about a new HAL for this
stuff in ALSA over the last couple of months. some people are looking
at specific cards for ideas about how to approach this. the model is
still that the application code will be (more or less) identical,
except perhaps for a few calls to toggle the choice of using h/w
features if they exist.

--p