i810 audio fixes 1/2

[Robert Reif]

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.

Paul Davis wrote:

> >I believe it makes sense for wine to keep the oss and alsa
> >drivers as low level as possible for users that require performance
> >over useability. The straight to hardware philosophy of direct sound
> >should be honored when possible. This would be appropriate for
> >games, voip or low latency music applications.
>
> ALSA is designed to avoid this sort of dichotomy. It does not matter
> to the app whether it opens "hw:0" or "plughw:0" or "plug:dmix:0" -
> the same code is used in every case. The fact that each of these
> virtual devices has quite different operating characteristics should
> be of interest to the user, but not to the code.
>
> There are places where this doesn't work. alsa-devel wants to hear
> about them, and plans to fix them.
>
> >If usability rather than performance (as in  multiple applications) is
> >important, then higher level drivers like jack or arts should be used.
>
> JACK is not aimed at usability, but performance. It enforces timing
> constraints rather than leaving it to a bunch of hapless apps to mess
> it up. You cannot hope to use JACK within Wine without intermediate
> buffering, which actually makes using JACK somewhat pointless. I say
> somewhat only because it still permits device sharing, but at the cost
> of losing sample accurate synchronization.
>
> --p