On Thu, 22 Nov 2001, Fernando Pablo Lopez-Lezcano wrote:
> > > what many people (all except Abramo IIRC) agreed to in the discussions
> > > on LAD was that in order to have ALSA provide an API that worked this
> > > way, you'd basically be completely hiding almost all of ALSA. So much
> > > so that making it part of the ALSA API is sort of beside the
> > > point.
> >
> > Paul, you're becoming to worry me... You're seeing confirmations of your
> > ideas here and there, where these does not exists.
> >
> > The discussion on LAD was essentially between you and me and almost no
> > other message pro/con your/my proposals was sent.
> >
> > After that some proposals have been sent (my soundboxes, your
> > laaga/jack, another proposal from Richard and other).
> >
> > Very little feedback has been given and nobody else has exited this
> > discussion convinced for a model or another.
>
> Ahem, _nobody_?
> On June 25 2001 I wrote (in linux-audio-dev):
>
> [begin quote]
> [Abramo wrote]
> > I think that the best solution would be the integration of
> > ALSA with LAAGA (with obvious mutual benefits). This likely
> > means some changes to ALSA API too.
>
> I would like LAAGA to be a fast, lean, easy to use, higher
> level (than the sound driver itself) API that _hides_ the
> hardware interface completely from all clients that use it. It
> seems to me that it should be kept separate from the driver
> itself so that it can potentially be ported to other drivers
> and or platforms.
> [end quote]
>
> I still think that JACK (was LAAGA) is at a different level of abstraction
> than the driver itself.
>
> Simplicity is what I would like to see. Writing an audio app with low
> latency and able to communicate with other similar apps should be simple
> and the developer should be able to concentrate on the audio part and not
> the sound driver and the hardware (with all the complexity that that
> adds). The idea of somebody saying to me "I want this many samples now and
> that's it" sounds really good to me. No formats, no rates, no cards or
> devices, instant compatibility with other apps, a trivially simple api.
Note that my discussion is not against simpler API. The benefits are
visible, but that JACK solves something in the speed issues.
Note, that it is not problem to force (using configuration) and optimize
ALSA plugins for one set of parameters and do requested conversions in the
final point (plugins). So that the applications can be written in very
simple way (requesting exactly required set of parameters). I personally
think, that all issues are already prepared in the current very flexible
and extensible ALSA PCM API as well.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
