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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
