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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
