Subject: Re: [linux-audio-dev] CSL-0.1.2 Release
From: Simon Per Soren Kagedal (simon_AT_cs.uoregon.edu)
Date: Fri Jun 08 2001 - 00:59:04 EEST
Hi Abramo, others,
On Thu, Jun 07, 2001 at 05:55:56PM +0200, Abramo Bagnara wrote:
> > I personally think that the SGI Audiofile library has one of the best
> > API's by far. It's generic and it supports a lot more than float32 data.
>
> Then I guess Paul have crossed an urban myth...
I'm not sure what you mean here, but please note that the audiofile
library deals with.. exactly that: loading and saving audio data in
all sorts of different formats. Of course it supports more than
float32 data; that is its purpose, and has nothing to do with what
we're discussing now. In fact I'm not sure why it was brought into
discussion.
> > In the meantime we have version 0.2.1 btw and the afVirtual methods are
> > implemented, too. It might lack support for some audioformats, but instead
> > writing new libs I'll rather put my efforts into putting more features
> > into libaudiofile. It even supports mp3 format by now, not officially
> > though, but there's a patch for it.
>
> The problem of efforts splitting is very severe as everybody (at least
> in theory) agree. This is why I advocate *one* API for everything.
You keep saying that, and I'm starting to be afraid that you actually
mean it. Please define "everything". Are you saying now that the
ALSA API and library is going to deal with all sorts of weird file
formats?
I say that a much bigger problem than efforts splitting is huge APIs
and applications that tries to be everything for everyone. The LAAGA
that is being discussed and proposed is an *abstraction*, a
simplification and it *intentionally* hides details that the audio
programs intended for its use should not / need not worry about. This
is a good thing. It is a proposed *layer on top of* ALSA, stopping no
one from using ALSA directly. If it's not, then here's some other
"duplicated efforts" for you:
* fread() vs. read()
* GTK vs. GDK
* TCP vs. IP :)
* OpenGL vs. whatever's below it
and so on...
> The same API to read/write from a file or a PCM. This is what I'm
> proposing.
Someone else proposes the same API to read from a local file, a file
in a tar.gz or an URL (e.g., gnome-vfs), and they'll want to use this
API whether it's an audio file or a word processor document.
Simon.
This archive was generated by hypermail 2b28 : Fri Jun 08 2001 - 03:18:14 EEST