future ALSA development

future ALSA development

[Jaroslav Kysela]

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
  - intended applications are
    - simple playback & recorders
    - DVD players
    - VoIP (and other audio conferencing) applications
    - very simple mixer applications
* 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
  - 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)?
* 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

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs




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

Re: future ALSA development

[Takashi Iwai]

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

Re: future ALSA development

[Jaroslav Kysela]

On Mon, 23 Jun 2003, Takashi Iwai wrote:

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

Well, I do not mind to change the base name again. It was only quick fix.

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

The new API is designed to keep it very simple. I think that the porting
to another language will be very simple, too.

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

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

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

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: future ALSA development

[Takashi Iwai]

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

Re: future ALSA development

[Paul Davis]

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

with a smile, i seem to recall noting that we'd end up with
lisp. quasimodo had gone through the same song and dance with a custom
configuration parser only to eventually find that guile made more
sense in almost every way. there is some adage about reinventing lisp
that i forget.

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

i'd like to put in a plug for a API that includes the one basic 
operation that JACK cannot implement on "generic" hardware:

	  "make the signal coming to the current capture input
	   appear at the output".

i.e. hardware monitoring. this is a really major flaw in JACK when run
on all consumer audio interfaces: they are quite capable of doing 
analog-level h/w monitoring, but JACK can't use it.

i know that the semantics need to be better defined than in my
sentence above.

--p


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

Re: future ALSA development

[Takashi Iwai]

At Mon, 23 Jun 2003 09:41:32 -0400,
Paul Davis wrote:
> 
> >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...
> 
> with a smile, i seem to recall noting that we'd end up with
> lisp. quasimodo had gone through the same song and dance with a custom
> configuration parser only to eventually find that guile made more
> sense in almost every way. there is some adage about reinventing lisp
> that i forget.
 
oh yeah.

btw, what was the biggest reason to change to XML in ardour?
it used guile once upon a time.


> >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.
> 
> i'd like to put in a plug for a API that includes the one basic 
> operation that JACK cannot implement on "generic" hardware:
> 
> 	  "make the signal coming to the current capture input
> 	   appear at the output".
> 
> i.e. hardware monitoring. this is a really major flaw in JACK when run
> on all consumer audio interfaces: they are quite capable of doing 
> analog-level h/w monitoring, but JACK can't use it.
> 
> i know that the semantics need to be better defined than in my
> sentence above.

this can be implemented better once when we have an ordinary-mixer
API.  the problem was that the action to do is different for each
card, and it's not abstracted (nor unified) so far.
the higher abstraction will absorb such a difference.


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

Re: future ALSA development

[Paul Davis]

>btw, what was the biggest reason to change to XML in ardour?
>it used guile once upon a time.

i didn't like the fact that the entire main() call had to be
encapsulated within a guile invocation (given what ardour does with
memory, threads, scheduling, etc, etc). i also didn't like having to
require guile be installed, and lastly, perhaps most importantly,
ardour was going to use XML for data files (session state information
etc) to further inter-operability, and so we decided to switch to XML
throughout.

>this can be implemented better once when we have an ordinary-mixer
>API.  the problem was that the action to do is different for each
>card, and it's not abstracted (nor unified) so far.
>the higher abstraction will absorb such a difference.

understood. i'd just to see this as a goal of whatever changes you
make. 


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

Re: future ALSA development

[Joern Nettingsmeier]

Jaroslav Kysela wrote:
 >>
 >>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.
 >
 > 						Jaroslav
 >

true if you only consider alsa. but on most systems, libxml2 is there 
anyway. <underwear type="asbestos">and imvho xml is less a matter of 
taste than lisp.</underwear> and xml is way easier to handle in other 
contexts (i'm thinking of auto.configuration stuff etc.)
otoh, the embedded guys will probably not like it, but then memory is 
becoming cheaper by the minute, and its additional size will be a moot 
point in the very near future.



-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)






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

Re: future ALSA development

[mru]

Joern Nettingsmeier <nettings@folkwang-hochschule.de> writes:

>  >>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.
>
> true if you only consider alsa. but on most systems, libxml2 is there
> anyway. <underwear type="asbestos">and imvho xml is less a matter of
> taste than lisp.</underwear> and xml is way easier to handle in other
> contexts (i'm thinking of auto.configuration stuff etc.)
> otoh, the embedded guys will probably not like it, but then memory is
> becoming cheaper by the minute, and its additional size will be a moot
> point in the very near future.

IMO, xml is a piece of bloated, error-prone hypeware.  Comparing it to
LISP doesn't make sense at all.  LISP is a programming language,
whereas XML is a markup language, albeit one that has come to be
misused a great deal.

-- 
Måns Rullgård
mru@users.sf.net



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

Re: future ALSA development

[Jaroslav Kysela]

On Tue, 24 Jun 2003, Joern Nettingsmeier wrote:

> Jaroslav Kysela wrote:
>  >>
>  >>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.
> 
> true if you only consider alsa. but on most systems, libxml2 is there 
> anyway. <underwear type="asbestos">and imvho xml is less a matter of 
> taste than lisp.</underwear> and xml is way easier to handle in other 
> contexts (i'm thinking of auto.configuration stuff etc.)
> otoh, the embedded guys will probably not like it, but then memory is 
> becoming cheaper by the minute, and its additional size will be a moot 
> point in the very near future.

Note that I do not want to squash the current configuration syntax at all.
I only want to extend the parsing and runtime evaluation of given 
configuration, because we need to describe complex things. I really think 
that XML is not a good choice at the moment for this job and if we use 
XML, we must define some language as well.

I am trying to rewrite some runtime evaluation parts of alsa.conf:

Original code:

# pre-load the configuration files

@hooks [
        {
                func load
                files [
                        "/etc/asound.conf"
                        "~/.asoundrc"
                ]
                errors false
        }
]

New code:

# pre-load the configuration files

@elisp "
        (load-conf \"/etc/asound.conf\" 0)
        (load-conf \"~/.asoundrc\" 0)
"

I think that it is much readable, is not?

More complicated example (original code as first):

# load card-specific configuration files (on request)

cards.@hooks [
        {
                func load
                files [
                        {
                                @func concat
                                strings [
                                        { @func datadir }
                                        "/cards/aliases.conf"
                                ]
                        }
                ]
        }
        {
                func load_for_all_cards
                files [
                        {
                                @func concat
                                strings [
                                        { @func datadir }
                                        "/cards/"
                                        { @func private_string }
                                        ".conf"
                                ]
                        }
                ]
                errors false
        }
]

New code:

# load card-specific configuration files (on request)

cards.@elisp "
        (load-conf (concat (data-dir) \"/cards/aliases.conf\") 0)
        (defun load-conf-all (card)
                (when (> card -1)
                        ((load-conf (concat (data-dir) "/cards/\" (driver card) \".conf\") 0)
                         (setq card (next-card card)))
                )
        )
        (load_conf_all (next-card -1))
"

There is much better view, what we need:

1) loops
2) conditions

Also, in this way, we can define only primitives and describe the main 
loops in lisp which is more universal.

Note: There may be a syntax error, because I am using lisp for the 
first time.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: future ALSA development

[iriXx]

Joern Nettingsmeier wrote:

> true if you only consider alsa. but on most systems, libxml2 is there 
> anyway. <underwear type="asbestos">and imvho xml is less a matter of 
> taste than lisp.</underwear> and xml is way easier to handle in other 
> contexts (i'm thinking of auto.configuration stuff etc.)
> otoh, the embedded guys will probably not like it, but then memory is 
> becoming cheaper by the minute, and its additional size will be a moot 
> point in the very near future.
> 
> 

ROFL im just reading my email over breakfast and had a splurting coffee 
moment wondering how many of us could see your underwear..... ;-)

m~

> 


-- 
        |\      _,,,---,,_
  ZZZzz /,`.-'`'    -.  ;-;;,_     HTTP 503: Too Busy
       |,4-  ) )-,_. ,\ (  `'-'
     '---''(_/--'  `-'\_) fL


  .::. www.iriXx.org .::. www.copyleftmedia.org.uk .::.

             gnupg key ID: AEB7A31E





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

Re: future ALSA development

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> On Tue, 24 Jun 2003, Joern Nettingsmeier wrote:
> 
> 
> # pre-load the configuration files
> 
> @elisp "
>         (load-conf \"/etc/asound.conf\" 0)
>         (load-conf \"~/.asoundrc\" 0)
> "

I'd suggest a simpler alternative:

- introduce a new type SND_CONFIG_TYPE_SEXP
- change parser to parse as an s-expression what begins with '('

The thing to think about is how to decide appropriate run time of sexp.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



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

Re: future ALSA development

[Paul Davis]

>@hooks [
>        {
>                func load
>                files [
>                        "/etc/asound.conf"
>                        "~/.asoundrc"
>                ]
>                errors false
>        }
>]
>
>New code:
>
># pre-load the configuration files
>
>@elisp "
>        (load-conf \"/etc/asound.conf\" 0)
>        (load-conf \"~/.asoundrc\" 0)
>"
>
>I think that it is much readable, is not?

slightly. but why on earth embed LISP within the existing language?
you now make users (and programmers working on alsa-lib) deal with
**TWO** languages. 

and just look at this ugliness:

>cards.@elisp "
>        (load-conf (concat (data-dir) \"/cards/aliases.conf\") 0)
>        (defun load-conf-all (card)
>                (when (> card -1)
>                        ((load-conf (concat (data-dir) "/cards/\" (driver card
>) \".conf\") 0)
>                         (setq card (next-card card)))
>                )
>        )
>        (load_conf_all (next-card -1))
>"

this is just another version of the kind of embedded quoting nightmare
that we all face when using shell scripts. the right form is:

(defun cards
        (load-conf (concat (data-dir) "/cards/aliases.conf") 0)
        (defun load-conf-all (card)
                (when (> card -1)
                        ((load-conf (concat (data-dir) "/cards/" 
				    (driver card) ".conf") 0)
                         (setq card (next-card card)))
                )
        )
        (load_conf_all (next-card -1))
)

Now *that's* elegant!

LISP can do everything that the existing language can do, it can do it
better, more flexibly, and more generically. I can see no
justification for making them both coexist. Either do the right thing
and use LISP or continue to hack the existing language "into
shape". Please. 

--p



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

Re: future ALSA development

[Jaroslav Kysela]

On Tue, 24 Jun 2003, Paul Davis wrote:

> this is just another version of the kind of embedded quoting nightmare
> that we all face when using shell scripts. the right form is:
> 
> (defun cards
>         (load-conf (concat (data-dir) "/cards/aliases.conf") 0)
>         (defun load-conf-all (card)
>                 (when (> card -1)
>                         ((load-conf (concat (data-dir) "/cards/" 
> 				    (driver card) ".conf") 0)
>                          (setq card (next-card card)))
>                 )
>         )
>         (load_conf_all (next-card -1))
> )
> 
> Now *that's* elegant!
> 
> LISP can do everything that the existing language can do, it can do it
> better, more flexibly, and more generically. I can see no
> justification for making them both coexist. Either do the right thing
> and use LISP or continue to hack the existing language "into
> shape". Please. 

There are two differences between lisp and alsa configuration language.
Lisp is standard dynamic language but the ALSA configuration is static
(if you ommit the runtime evaluation hacks added to enhance functinality).

It is something similar like "HTML" and "Java script". The first one is 
good to describe the static part of web pages, but if you want something 
dynamic, you have to use another embeded language.

Note that 'cards.@elisp "code"' part expands the whole cards tree to 
(example):

cards.pcm.EMU10K1.front { EMU10K1.specific.configuration.is.here }
cards.pcm.YMFPCI.rear { YMFPCI...... }
						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: future ALSA development

[Paul Davis]

>There are two differences between lisp and alsa configuration language.
>Lisp is standard dynamic language but the ALSA configuration is static
>(if you ommit the runtime evaluation hacks added to enhance functinality).

but the runtime evaluation hacks are precisely what give rise to the
problems. you and abramo may have conceived of it as a static language
in the first place, but it clearly has, along with just about every other
"small language", mutated into something else. the story of PHP is one
of the more recent illustrations of this.

>It is something similar like "HTML" and "Java script". The first one is 
>good to describe the static part of web pages, but if you want something 
>dynamic, you have to use another embeded language.

or use a real language for the whole thing. this is not the web. there
is no reason to use a few lines of static container code (e.g. HTML)
to wrap a real programming language (e.g. Java). 




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

Re: future ALSA development

[Giuliano Pochini]

On 23-Jun-2003 Takashi Iwai wrote:
> 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.

It has to be simple from the application's point of view, but the
implementation will be quite complex. Things as simple as setting
the volume can be all but trivial given the complexity of the
control API.

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

Lisp should be fine, although it's not very user-friendly. But what the
interpreter is supposed to do ?  Is it possible to create an ordinary
mixer control that the hw doesn't support ?  For example: a card may not
have an hw master volume control, but the ordinary mixer has to provide
it. Is the lisp config file generic enough to provide a function to
emulate the master volume control it by changing the volume controls
of all single channels ?  It's not trivial at all to do such a thing
with a "normal" config file, but it's possible with an interpreter. The
question is: is it worth the effort ?  Or is it better to force all
lowlevel drivers to provide a minimal set of ordinary controls ?

>>   - 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)?

And what about Brainfuck ?  The compiler is a few hundred bytes
long. Ah, no, it hasn't functions. :)))))

>> * 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 an Alsa module is quite easy to write.


Bye.



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

Re: future ALSA development

[Jaroslav Kysela]

On Tue, 24 Jun 2003, Giuliano Pochini wrote:

> Lisp should be fine, although it's not very user-friendly. But what the
> interpreter is supposed to do ?  Is it possible to create an ordinary
> mixer control that the hw doesn't support ?  For example: a card may not
> have an hw master volume control, but the ordinary mixer has to provide
> it. Is the lisp config file generic enough to provide a function to
> emulate the master volume control it by changing the volume controls
> of all single channels ?  It's not trivial at all to do such a thing
> with a "normal" config file, but it's possible with an interpreter. The
> question is: is it worth the effort ?  Or is it better to force all
> lowlevel drivers to provide a minimal set of ordinary controls ?

I think that it's worth to let define multiple virtual mixer devices for
multichannel cards (if required) and I can find more examples in this
area. You cannot do that in the kernel space without adding more code and
this is exactly what we do not want.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: future ALSA development

[Takashi Iwai]

At Tue, 24 Jun 2003 08:16:18 -0400,
Paul Davis wrote:
> 
> >It is something similar like "HTML" and "Java script". The first one is 
> >good to describe the static part of web pages, but if you want something 
> >dynamic, you have to use another embeded language.
> 
> or use a real language for the whole thing. this is not the web. there
> is no reason to use a few lines of static container code (e.g. HTML)
> to wrap a real programming language (e.g. Java). 

i agree with Paul.
of course, it's a pain that all configuration syntax is changed.
but for me, it looks far more consistent to describe the whole thing
with the same syntax.

well, you might consider the compatibility issue.  yes, that's another
big thing to discuss...


i believe, if we change the configuration syntax, it would be better
to branch the development tree (or jump the version number).
the current system works well already in many fields, so it's nice to
keep the stable series.


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

Re: future ALSA development

[Takashi Iwai]

At Tue, 24 Jun 2003 15:04:22 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 24 Jun 2003, Giuliano Pochini wrote:
> 
> > Lisp should be fine, although it's not very user-friendly. But what the
> > interpreter is supposed to do ?  Is it possible to create an ordinary
> > mixer control that the hw doesn't support ?  For example: a card may not
> > have an hw master volume control, but the ordinary mixer has to provide
> > it. Is the lisp config file generic enough to provide a function to
> > emulate the master volume control it by changing the volume controls
> > of all single channels ?  It's not trivial at all to do such a thing
> > with a "normal" config file, but it's possible with an interpreter. The
> > question is: is it worth the effort ?  Or is it better to force all
> > lowlevel drivers to provide a minimal set of ordinary controls ?
> 
> I think that it's worth to let define multiple virtual mixer devices for
> multichannel cards (if required) and I can find more examples in this
> area. You cannot do that in the kernel space without adding more code and
> this is exactly what we do not want.

yes, this way is also helpful to solve the problem of "different
speaker configurations", as posted in another thread.


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

Re: future ALSA development

[Jaroslav Kysela]

On Tue, 24 Jun 2003, Takashi Iwai wrote:

> At Tue, 24 Jun 2003 08:16:18 -0400,
> Paul Davis wrote:
> > 
> > >It is something similar like "HTML" and "Java script". The first one is 
> > >good to describe the static part of web pages, but if you want something 
> > >dynamic, you have to use another embeded language.
> > 
> > or use a real language for the whole thing. this is not the web. there
> > is no reason to use a few lines of static container code (e.g. HTML)
> > to wrap a real programming language (e.g. Java). 
> 
> i agree with Paul.
> of course, it's a pain that all configuration syntax is changed.
> but for me, it looks far more consistent to describe the whole thing
> with the same syntax.
>
> well, you might consider the compatibility issue.  yes, that's another
> big thing to discuss...

I will try to evaluate the lisp possibilities in this area. I also think 
that the old and new configuration might co-exist for awhile. Especially, 
the new extensions (like mixer configuration) might use the new 
configuration syntax.

> i believe, if we change the configuration syntax, it would be better
> to branch the development tree (or jump the version number).
> the current system works well already in many fields, so it's nice to
> keep the stable series.

We can do it when we need to break the compatibility behaviour.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs




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

PCMCIA In Kernel Or In ALSA Driver?

[Len Moskowitz]

Hi to all,

We're setting up a PDAudio-CF card.

I note that the  configuration asks whether we want kernel or ALSA PCMCIA
support: does it
matter to the PDAudio-CF card driver?


Len M.



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

Re: PCMCIA In Kernel Or In ALSA Driver?

[Jaroslav Kysela]

On Wed, 25 Jun 2003, Len Moskowitz wrote:

> Hi to all,
> 
> We're setting up a PDAudio-CF card.
> 
> I note that the  configuration asks whether we want kernel or ALSA PCMCIA
> support: does it
> matter to the PDAudio-CF card driver?

Yes, both should be enabled (kernel + ALSA PCMCIA support).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: future ALSA development

[Takashi Iwai]

At Tue, 24 Jun 2003 20:28:08 +0200 (CEST),
Jaroslav wrote:
> 
> > i believe, if we change the configuration syntax, it would be better
> > to branch the development tree (or jump the version number).
> > the current system works well already in many fields, so it's nice to
> > keep the stable series.
> 
> We can do it when we need to break the compatibility behaviour.

hmm, i think we need now some release engineering.

ALSA 0.9.x series has been released as the STABLE line, and that means
that the API should be kept as much as possible.  i don't think it's good
to include the experimental code for a fundamental change to such a
tree (even in cvs).

i know it's a bit annoying to keep both different cvs branches
up-to-date.  but now it's the time to separate clearly what we've done
and what we'll do.  this will make it easy to release the newer 0.9.x
tarball, too.

well, if we were to use bitkeeper, it would be easier to keep the different
trees in sync... :)


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: future ALSA development

[Kai Vehmanen]

Ok, this is a bit late, but hopefully not too late. :)

On Tue, 24 Jun 2003, Joern Nettingsmeier wrote:
>>> other people might propose XML.  then it becomes to a question whether
>> I think that XML is too overkill for our purposes.
> otoh, the embedded guys will probably not like it, but then memory is 
> becoming cheaper by the minute, and its additional size will be a moot 
> point in the very near future.

This is a dangerous argument. While it's that true memory and cpu power
are becoming cheaper and cheaper all the time, minimizing resource usage
is still as important as ever. With big volume products, small things make
a big difference in the overall picture (i.e. which products survive in
the market). Saving an extra 100kB can make a huge difference if it allows
you to use a smaller flash chip on your device.

This doesn't mean ALSA should not take advantage of any additional
libraries, but these additions should not create new dependendencies to
the core system. In other words you should be able to build a compact
version of ALSA user-space libs and tools, and one that is cross-compiler
friendly. Otherwise people will be tempted to use OSS or write their own
drivers.

Already alsa-lib has some features that are not so good from embedded 
perspective:

- not a small lib; with default settings around 0.5MB; this 
  is an extra 0.5MB compared to just using OSS where there is no lib
- use of more advanced c-lib features such as dynamic loading (dlopen(), 
  etc); these can cause problems if you try to use libasound with other
  c-libs than glibc

... but, but, of course libasound also provides lots of great
functionality, so it's still a good alternative. And also, app developers
can always manually scale down the libasound build, or even write their
apps to directly communicate with ALSA's kernel interface. But if using
ALSA becomes too difficult, embedded-linux community will default to OSS
and/or custom solutions, which I think is a bad thing... (at least I'd
like to run ALSA apps on Linux PDAs and who-knows-what other gadgets that
might be released in the future).

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: future ALSA development

[Kai Vehmanen]

On Sun, 22 Jun 2003, Jaroslav Kysela wrote:

> 	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

These are very welcome additions, especially the mixer part! Although most
people can easily use (for instance) alsamixer, the controls on some cards
are hopelessly confusing. Having all cards publish a simple set of
standard controls will significantly improve ALSA's user-friendliness. It
would be good if even the high-end cards would provide a mapping to these
simple controls. Ideally, a DVD player using the simple PCM and mixer
interfaces would work as expected even if your card is a Hammerfall or
some ice1712-based.

> * investigate a lisp integration to the current configuration syntax
[...]
>   - I don't rely on lisp, but what another interpreter with function
>     definition has only 22kB binary (slisp-1.2 - i686)?

Hmm, it'd be great if this functionality was optional (at build time). 
Although I must admit 22kB is not much... 

> * initiate a development of a graphical tool which will manage
>   the alsa configuration files (~/.asoundrc)

One possible addtional item (not alsa-lib specific):

* making alsa-conf the primary tool for setting up ALSA user-space

I'm not sure what's the status of alsa-conf is currently, but based on the 
mailing list activity and ALSA websites, it doesn't seem to be widely 
used. OTOH; the few times I've tried it, it has worked well. And what's 
most important, it solves two of the top-3 user problems with setting up 
ALSA:

1. Finding out what audio hardware you have and what is the
   correct ALSA module.
2. Editing modules.conf.
3. Managing to compile alsa-driver against kernel sources.

... alsa-conf solves (1) and (2), while (3) will be history once linux-2.6
is released. Hmm, editing asoundrc is also one common issue, but as
asoundrc is not required to get a basic ALSA setup up, it's not in my
top-3. :)

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: future ALSA development

[Kai Vehmanen]

On Thu, 3 Jul 2003, Kai Vehmanen wrote:

> * making alsa-conf the primary tool for setting up ALSA user-space

Ugh, that should "primary tool for setting up ALSA (kernel) drivers".
Hmm, I guess we could have two tools, one for drivers (current alsa-conf)
and one for user-space (asoundrc editor).

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: future ALSA development

[Thomas Charbonnel]

> Hello all,
>
> 	here are my next goals for the ALSA library development (short
> term). I invite all developers to comment these directions.
>

[...]

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

One point I would like to bring to focus is how sound hardware state
persistance is dealt with. The limits of alsactl are showing up with
hardware like the hdsp, were the card might not be fully initialized (or
not even present yet, e.g. cardbus) at boot time. We're more and more
likely to have to deal with such external hotpluggable devices (pcmcia,
firewire, usb), where full initialization can happen any time after the
boot process, and we can't expect the average user to be scripting around.

IMHO state restoration could be :
* triggered by the driver, at the appropriate time, depending maybe on
some system configuration options.
* initiated by the user, through the configuration GUI.

We could have a default configuration restored by the driver at
initialization time, and a set of named configurations the user could
save/restore/set as default using the GUI.

There are probably other ways to handle this, I'm waiting for your comments.

Thomas





-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: future ALSA development

[Takashi Iwai]

At Thu, 3 Jul 2003 16:39:36 +0300 (EEST),
Kai Vehmanen wrote:
> 
> Ok, this is a bit late, but hopefully not too late. :)
> 
> On Tue, 24 Jun 2003, Joern Nettingsmeier wrote:
> >>> other people might propose XML.  then it becomes to a question whether
> >> I think that XML is too overkill for our purposes.
> > otoh, the embedded guys will probably not like it, but then memory is 
> > becoming cheaper by the minute, and its additional size will be a moot 
> > point in the very near future.
> 
> This is a dangerous argument. While it's that true memory and cpu power
> are becoming cheaper and cheaper all the time, minimizing resource usage
> is still as important as ever. With big volume products, small things make
> a big difference in the overall picture (i.e. which products survive in
> the market). Saving an extra 100kB can make a huge difference if it allows
> you to use a smaller flash chip on your device.
> 
> This doesn't mean ALSA should not take advantage of any additional
> libraries, but these additions should not create new dependendencies to
> the core system. In other words you should be able to build a compact
> version of ALSA user-space libs and tools, and one that is cross-compiler
> friendly. Otherwise people will be tempted to use OSS or write their own
> drivers.
> 
> Already alsa-lib has some features that are not so good from embedded 
> perspective:
> 
> - not a small lib; with default settings around 0.5MB; this 
>   is an extra 0.5MB compared to just using OSS where there is no lib

that's true.

> - use of more advanced c-lib features such as dynamic loading (dlopen(), 
>   etc); these can cause problems if you try to use libasound with other
>   c-libs than glibc

it's possible to create a static library which doesn't need dlopen().
but it will eventually link the whole plugin objects statically.

so, maybe a compromise is to add configure options or something to
choose the components (e.g. plugins) to be built in.  this will reduce
the size of binary, too.

there are some parts which use glibc's extension (like jump to label
address or function-in-function).  but these can be fixed with the
standard style, too.  they are mostly optmizations only.


> ... but, but, of course libasound also provides lots of great
> functionality, so it's still a good alternative. And also, app developers
> can always manually scale down the libasound build,

yep

> or even write their
> apps to directly communicate with ALSA's kernel interface.

mmm, this should be never done.
one of the reason to have alsa-lib is to avoid this.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: future ALSA development

[Takashi Iwai]

At Thu, 3 Jul 2003 18:05:08 +0200 (CEST),
Thomas Charbonnel wrote:
> 
> > Hello all,
> >
> > 	here are my next goals for the ALSA library development (short
> > term). I invite all developers to comment these directions.
> >
> 
> [...]
> 
> > * 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
> >
> 
> One point I would like to bring to focus is how sound hardware state
> persistance is dealt with. The limits of alsactl are showing up with
> hardware like the hdsp, were the card might not be fully initialized (or
> not even present yet, e.g. cardbus) at boot time. We're more and more
> likely to have to deal with such external hotpluggable devices (pcmcia,
> firewire, usb), where full initialization can happen any time after the
> boot process, and we can't expect the average user to be scripting around.
> 
> IMHO state restoration could be :
> * triggered by the driver, at the appropriate time, depending maybe on
> some system configuration options.

it would be feasible only if we have a certain daemon.
otherwise, i don't think its a good style to invoke a user-space tool
from the kernel driver.

> * initiated by the user, through the configuration GUI.
 
or: more clever hotplug scripts.

basically, the whole initialization stuff for such dynamic devices is
the job of hotplug manager.  so, we can provide a proper init/delete
script for each card.  e.g. loading the firmware, then set up the
default or restore the last status.

but yes, for this way, it would be nice to have a "state", so that
alsactl can know whether the data to restore matches with the current
state.  in this way, the unmatching data can be ignored by the first
call of alsactl in the init script.


Takashi



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

ALSA in embedded use (was: Re: future ALSA development)

[Kai Vehmanen]

Hi,

this reply comes a bit late, but I guess this is still very much a 
relevant topic.

On Mon, 7 Jul 2003, Takashi Iwai wrote:
>> Already alsa-lib has some features that are not so good from embedded 
>> perspective:
>> - not a small lib; with default settings around 0.5MB; this 
>>   is an extra 0.5MB compared to just using OSS where there is no lib
> that's true.

I yesterday installed ALSA 0.9.6 on a iPaq and libasound.so was 688kB
when stripped (2.3MB with symbols).

One thing to note is that latest Familiar distro release (0.7) from 
handhelds.org (the most popular distro for iPaqs and various other
handhelds), now includes ALSA kernel drivers (alsa-modules package), but 
no userspace ALSA packages. 

This is a prime example what we need to avoid (ALSA used only for the
OSS-emulation). Now I'm not subscribed to the familiar mailing lists, so
I'm not 100% sure of the reasons why userspace was left out. Also, the
unstable package tree seems to have packages for alsa-lib and alsa-utils,
so situation might change.

Still, my iPaq has only 16MB of space for the root system. After 
installing the basic GPE2 image, I only have 1.1MB left for my apps. 
In this situation the 688kB for alsa-lib plus some more for basic ALSA 
utils is a real problem.

>> - use of more advanced c-lib features such as dynamic loading (dlopen(), 
> it's possible to create a static library which doesn't need dlopen().
> but it will eventually link the whole plugin objects statically.
[...]
> so, maybe a compromise is to add configure options or something to
> choose the components (e.g. plugins) to be built in.  this will reduce
> the size of binary, too.

Ok, this is good to know. Does this already work now (i.e. when dlopen()
is not available)? 

> there are some parts which use glibc's extension (like jump to label
> address or function-in-function).  but these can be fixed with the
> standard style, too.  they are mostly optmizations only.

Hmm, so I guess we'd need someone who actively uses dietlibc (or some 
other) with ALSA. Otherwise it will be hard to keep alsa-lib 
clean from glibc-isms. Any volunteers? :)

>> apps to directly communicate with ALSA's kernel interface.
> mmm, this should be never done.
> one of the reason to have alsa-lib is to avoid this.

But the risk is there, see my comments above about libasound size.

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ALSA in embedded use (was: Re: future ALSA development)

[Takashi Iwai]

At Wed, 1 Oct 2003 12:37:48 +0300 (EEST),
Kai Vehmanen wrote:
> 
> >> - use of more advanced c-lib features such as dynamic loading (dlopen(), 
> > it's possible to create a static library which doesn't need dlopen().
> > but it will eventually link the whole plugin objects statically.
> [...]
> > so, maybe a compromise is to add configure options or something to
> > choose the components (e.g. plugins) to be built in.  this will reduce
> > the size of binary, too.
> 
> Ok, this is good to know. Does this already work now (i.e. when dlopen()
> is not available)? 

no, volunteers wanted :)

> > there are some parts which use glibc's extension (like jump to label
> > address or function-in-function).  but these can be fixed with the
> > standard style, too.  they are mostly optmizations only.
> 
> Hmm, so I guess we'd need someone who actively uses dietlibc (or some 
> other) with ALSA. Otherwise it will be hard to keep alsa-lib 
> clean from glibc-isms. Any volunteers? :)

ah, sorry, the above is a typo.  i wanted to write "gcc".
it should be independent from glibc or dietlibc.


> >> apps to directly communicate with ALSA's kernel interface.
> > mmm, this should be never done.
> > one of the reason to have alsa-lib is to avoid this.
> 
> But the risk is there, see my comments above about libasound size.

for that, we'll need a diet alsa-lib.
this wouldn't be too big, since it's just a wrapper.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf