From: Takashi Iwai <tiwai@suse.de>
To: ALSA development <alsa-devel@alsa-project.org>
Subject: Re: future ALSA development
Date: Mon, 23 Jun 2003 15:13:06 +0200 [thread overview]
Message-ID: <s5hof0p2azh.wl@alsa2.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0306231338350.1838-100000@pnote.perex-int.cz>
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
next prev parent reply other threads:[~2003-06-23 13:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-22 19:10 future ALSA development Jaroslav Kysela
2003-06-23 11:14 ` Takashi Iwai
2003-06-23 12:01 ` Jaroslav Kysela
2003-06-23 13:13 ` Takashi Iwai [this message]
2003-06-23 13:41 ` Paul Davis
2003-06-23 13:51 ` Takashi Iwai
2003-06-23 14:18 ` Paul Davis
2003-06-23 22:22 ` Joern Nettingsmeier
2003-06-24 7:51 ` mru
2003-06-24 8:14 ` Jaroslav Kysela
2003-06-24 11:19 ` Abramo Bagnara
2003-06-24 11:43 ` Paul Davis
2003-06-24 11:56 ` Jaroslav Kysela
2003-06-24 12:16 ` Paul Davis
2003-06-24 17:11 ` Takashi Iwai
2003-06-24 18:28 ` Jaroslav Kysela
2003-06-25 17:49 ` PCMCIA In Kernel Or In ALSA Driver? Len Moskowitz
2003-06-25 18:51 ` Jaroslav Kysela
2003-06-30 10:17 ` future ALSA development Takashi Iwai
2003-06-24 8:28 ` iriXx
2003-07-03 13:39 ` Kai Vehmanen
2003-07-07 11:26 ` Takashi Iwai
2003-10-01 9:37 ` ALSA in embedded use (was: Re: future ALSA development) Kai Vehmanen
2003-10-01 13:13 ` Takashi Iwai
2003-06-24 12:52 ` future ALSA development Giuliano Pochini
2003-06-24 13:04 ` Jaroslav Kysela
2003-06-24 17:12 ` Takashi Iwai
2003-07-03 14:21 ` Kai Vehmanen
2003-07-03 14:36 ` Kai Vehmanen
2003-07-03 16:05 ` Thomas Charbonnel
2003-07-07 11:37 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hof0p2azh.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox