At Mon, 23 Jun 2003 14:01:08 +0200 (CEST), Jaroslav wrote: > > > > * investigate a lisp integration to the current configuration syntax > > > - we need to describe the relations between high level abstract > > > layer (ordinary mixer) and current universal controls (very lowlevel); > > > it seems that the simple configuration is not able to describe > > > these (in most cases) very complicated paths > > > > yep. > > > > > - note that describing of these relations might be used also for > > > another mixer interfaces (simple mixer for example) > > > - I don't rely on lisp, but what another interpreter with function > > > definition has only 22kB binary (slisp-1.2 - i686)? > > > > surely it's nice but i don't think it's good to introduce more > > complexity into the asoundrc syntax. or, if you mean an external > > We need to introduce the configuration extensions. At this stage, > I want to investigate, if the runtime configuration modification (runtime > functions) might be converted to lisp rather than doing more or less ugly > hacks in our configuration syntax parsers. 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...
> > database for describing the mixer configuration, it would be the > > outside of the (old) simple-mixer API, IMO. > > > > in that case, anyway, we can drop simple-mixer API and replace with > > the new one. the strategy used in the simple-mixer API can be > > integrated into the new (ordinary) mixer API. > > I think that the ordinary mixer API and simple mixer API does not have > much common parts for complicated hardware. The ordinary mixer API is very > highlevel and tied up to specified playback / capture streams, but the > simple mixer API is still only a translation between universal controls > and mixer applications. I think that both should be configurable, but the > question is how much of these configurations can be shared. I would keep > the configurations separate. 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. > > about lisp: i don't have objections. i like lisp, too :) > > the parser can be quite small, so if we build the parser in alsa-lib, > > it's a good choice. > > > > other people might propose XML. then it becomes to a question whether > > alsa-lib should rely on other libs... > > I think that XML is too overkill for our purposes. i don't think it's overkill but just a question of library dependency. and, writing a (good-readable) XML by hand is (not always but often) a hard work. so i myself don't buy this unless any other good reason appears. Takashi ------------------------------------------------------- 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
