[LAU] Daemons, daemons...kill those daemons.
compose59 at gmail.com
Mon Jun 15 02:05:51 EDT 2009
On Sun, Jun 14, 2009 at 11:51 PM, Fons Adriaensen<fons at kokkinizita.net> wrote:
> 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
> 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
> 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.
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
>From just one "power" user's perspective, having alsa only do its bit
in the kernel, and jack do the rest sounds appealing. I think the alsa
team continue to do a great job, but maybe their workload could be
even easier to manage if they just did H/W devices/modules, and let
Jack "manage" as it seems to be specifically designed to do.
I use a lot of midi (big orchestral templates), and have had quite a
few adventures with timing, ports, etc..using alsa. I respectfully
suggest that in this area too, alsa only occupies itself in the
kernel, and jackmidi assumes the sample accurate responsibility for
any midi requirements.
Ergo, i respectfully ask devs for the few programmes that still use
alsa midi, to consider a push towards replacing it with, or adding
jackmidi, and then we'll all be singing from the same orchestral
score, to sample accurate level.
Then alsa can do what it does best, at kernel/hw device level, and
jack can take the blame/credit for the rest....
midi-subscribe at openoctave.org
development-subscribe at openoctave.org,
More information about the Linux-audio-user