Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularizationof audio component
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Fri May 04 2001 - 23:26:26 EEST
Abramo,
> > One API per task is appropriate, but in this case I think there are two
> > tasks. The alsa api has always made an effort to expose all of the
> > features of the sound hardware, which is great. LAAGA (or rewire, etc) is
> > about providing simple enviroment for applications. This seems, to me, to
> > be better served by more than one api.
>
> What's different from to read audio from an hardware capture stream and
> to read audio from an mp3 decoder, a FX, a synthesizer?
>
> They have the same contents: audio. Now why I'd need to write different
> input module to be able to access each of them?
>
There are two main differences:
Paramaters - different audio hardware has different capabilities and
features. An api that interacts with hardware needs to be able to query
and set these features.
Format - audio hardware can provide a variety of formats.
Both of these issues, format and paramaters, make the alsa api the
complicated api that it is. Your assertion (in the form of a question)
that reading from hardware is the same as reading from an application is
built upon the premise that audio data is audio data. This is
fundamentally not true.
One of the design decisions of LADSPA and the proposed LAAGA is that all
audio data will be floating point. This is not a limitation of the api
but a good design decision. You have described conversion between formats
as having no cost in the past - this is not true.
- format conversions use of cpu time that is already in short supply
- format conversions to fixed point types _severely_ limits the headroom
of the system and introduces multiple points where clipping can occur.
Additionally, there is no reason for every single application to have to
deal with the complexity of, potentially, dealing with hardware. It just
doesn't make sense!
> > > LAAGA on LADSPA on CSL on ARTS on OSS? No thanks. (the example is
> > > arbitrary)
> > >
> > > I'm proposing a variation of the good old principle "Everything is a
> > > file": a general purpose honest API for audio stream transfer/control.
> > >
> >
> > But already in the alsa api everything is not a file. As long as alsa lib
> > is required this abstraction is already gone. This is not a bad thing,
> > just a different thing.
>
> I've said it's a *variant*. The right slogan (if needed ;-) might be
> "every audio stream is an audio stream" or "one API for everything".
>
> I think that the benefits to have only one API are evident, I'd like to
> understand better the drawbacks you see.
>
> But please don't tell me: "Hey the ALSA PCM API, is too versatile for
> this, something simpler will do the same job..." because this is a fake
> argument: versatility is not something that impose extra efforts.
>
> I'd like to hear something like: "In this way you cannot reach the
> performance level we need, because... etc." or "That solution does not
> solve this problem: ...." and something like that.
>
Well, how can I argue when you limit what you will listen to?
There is a difference between complexity and versatility. The complexity
of the alsa api is dictated by the complexity of audio hardware - as it
should be. An application level (as opposed to hardware level) api should
not have to deal with this complexity.
Similarly, simplicity is not always a limitation. An api should only be
as large as it needs to be. My two respectful questions for you are:
What drawbacks to you see to multiple api layers?
What are the chances that the kernel developers will accept the alsa lib
(which is stated to be necessary to the alsa kernel api) if it contains a
complex application framework?
Before this discussion goes any further I would like to say that I like
the current alsa lib api and respect your efforts very much. You have
done much for audio programming under linux! Just thought I should
mention this . . .
Karl
> --
> Abramo Bagnara mailto:abramo_AT_alsa-project.org
>
> Opera Unica Phone: +39.546.656023
> Via Emilia Interna, 140
> 48014 Castel Bolognese (RA) - Italy
>
> ALSA project http://www.alsa-project.org
> It sounds good!
> ------
> To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send message
> 'unsubscribe' in the body of message to <alsa-devel-request_AT_alsa-project.org>.
> BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs
>
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| www.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Sat May 05 2001 - 00:04:23 EEST