15 Jun
2009
15 Jun
'09
4:05 a.m.
On Sun, Jun 14, 2009 at 11:51 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
On Sun, Jun 14, 2009 at 02:38:56PM -0400, Paul Davis
wrote:
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....
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org,
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
From just one "power" user's perspective, having alsa only do its bit