Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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