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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-userReceived on Mon Jun 15 00:15:03 2009
This archive was generated by hypermail 2.1.8 : Mon Jun 15 2009 - 00:15:03 EEST