Re: future ALSA development

[Paul Davis <paul@linuxaudiosystems.com>]

>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