14 Jun
2009
14 Jun
'09
5:55 p.m.
On Sun, Jun 14, 2009 at 02:38:56PM -0400, Paul Davis wrote:
There is no "ALSA mixer" for multiplexing
apps unless you mean dmix
and or a "share" plugin. Both of these "work" for some definition of
the term, but both have also been tested and found wanting as a
general solution to the problem of shared h/w access.
'For some value of the term' is quite correct, and one may wonder
why that is the case.
AFAICS, Alsa has shot itself in the foot by trying to provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
If such a library had been created by the ALSA devs instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
Just my 2 eurocents, of course.
Ciao,
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.