Re: future ALSA development

[Takashi Iwai <tiwai@suse.de>]

At Sun, 22 Jun 2003 21:10:31 +0200 (CEST),
Jaroslav wrote:
> 
> Hello all,
> 
> 	here are my next goals for the ALSA library development (short 
> term). I invite all developers to comment these directions.
> 
> * create ordinary pcm & mixer interfaces
>   - proposed headers are in current CVS
>     - alsa-lib/include/pcm_ordinary.h
>     - alsa-lib/include/mixer_ordinary.h

i know the name conflictions of the word "simple" but i feel this
naming not so intuitive...  it's just my tastes, though.

a native english person might have a better idea?


>   - intended applications are
>     - simple playback & recorders
>     - DVD players
>     - VoIP (and other audio conferencing) applications
>     - very simple mixer applications

nice!

do you think it's easy to bind to other languages, too?
i've thought of C++ wrapper for the current alsa-lib, but it's way
complicated because of its opaque struct style.

> * 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
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.

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...


> * initiate a development of a graphical tool which will manage
>   the alsa configuration files (~/.asoundrc)
>   - we need a rapid development tool; I slowly became a fan of python and
>     Qt has rich number of widgets; python + PyQt seems to me a good idea
>   - using python requires to write a GPLed ALSA 0.9 -> python wrapper

no objection at all.  python is powerful enough.
and once if such a tool is written in a certain language, it's easy to
port to other languages, too.


ciao,

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