>my afraid is that the more control flows like conditionals may lead to
>a difficulty for a parser utility. i.e. the parser itself would be
>like an interprerter. but it's true that an extesion is needed
>anyway...
with a smile, i seem to recall noting that we'd end up with
lisp. quasimodo had gone through the same song and dance with a custom
configuration parser only to eventually find that guile made more
sense in almost every way. there is some adage about reinventing lisp
that i forget.
>IMO, the current simple-mixer API is still too complicated and not a
>good abstraction. as you mentioned, there is a big gap between the
>low-level expressions (control API) and the reasonable mixer
>appearance. the extra information for the mixer would be needed to
>fill this gap, too.
i'd like to put in a plug for a API that includes the one basic
operation that JACK cannot implement on "generic" hardware:
"make the signal coming to the current capture input
appear at the output".
i.e. hardware monitoring. this is a really major flaw in JACK when run
on all consumer audio interfaces: they are quite capable of doing
analog-level h/w monitoring, but JACK can't use it.
i know that the semantics need to be better defined than in my
sentence above.
--p
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
