Re: [linux-audio-dev] CSL-0.1.2 Release

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] CSL-0.1.2 Release
From: Alexander Ehlert (alexander.ehlert_AT_uni-tuebingen.de)
Date: Thu Jun 07 2001 - 19:14:13 EEST


Hi,

> The same API to read/write from a file or a PCM. This is what I'm
> proposing.

Sorry, but I don't think that's the right way to go. Just have a look
at SGI's API's. They rock.

> No PCM treats float data currently, but it is a work of less than one
> hour to add a pcm_float class.

Why so specific? This is why the ALSA API is so bloated. If someone
requests playing integer, double, whatever we need a pcm_integer,
a pcm_integer or a pcm_whatever class?

Just open a pcm stream and then set the playback mode! Have a look at
OpenGL how thinks are done or the SGI audiofile library. It would
be much more generic just adding a method to the pcm_t that allows
setting a playback mode a la

set_pcm_playback_mode(handle, ALSA_NON_INTERLEAVED |
ALSA_SAMPLETYPE_FLOAT, channelcnt)

You don't need a new class. And this way the API won't change all the
time. It's important to provide an API with standard classes that
have a high abstraction level for whatever you do. You can always
easily add modes, types etc. and implement it in the underlying lib.
But don't add new types, methods, etc. for every feature. Again,
look at audiofile. If you want to support a new filetype you don't
add new methods for the filetype and new types, you add a mode to some
enumeration in the header file and thats it. You won't even need
that if you're application doesn't care about the type and just wants to
do
afOpen(file)
afRead(file, buffer)
and get information about number of channels and stuff with some other
methods I can't recall atm.

Cheers, mag


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jun 07 2001 - 19:54:41 EEST