Subject: Re: [linux-audio-dev] sound API libraries, servers, etc.
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Apr 27 2001 - 01:26:23 EEST
>Here are my opinions on implementation.
>
>My current "recording" server has following features I like (doesn't mean
>such API should have all these):
[ ... features ... ]
all of these features can be added on-top of AES by adding another
client to it. the key points of AES' design are low latency created by
in-process plugins. 32 bit float is already there.
note that i spent quite some discussing the extreme likelihood of
adding network-output channels to the AudioEngine object today. It
would end up with three classes of channel: Hardware (physical
connectors on an audio interface), InternalBus (self-evident, i trust)
and Network. i'm very excited by this idea. there's lots more to think
about, however.
>> - read(int channel_id, ...)
>
>I think there should be one channel streaming/block IO and also interleaved
>multichannel streaming/block IO.
AES doesn't support interleaved format because it implies extra
buffering, which in turn implies more memory and use and more
cycles. if a client needs this, it must do the deinterleaving
itself.
I'm not saying we should never support this, but it can get rather complex.
>MY biggest problem is to keep cross-platform compatiblity. OSS runs on
>multiple platforms. ALSA's biggest problem is that it currently runs only on
>Linux and QNX. Not to even mention about f*cking Microsoft APIs.
The AES API doesn't include anything about ALSA whatsoever. The
AudioEngine implementation just happens to use an
ALSA::MultiChannelDevice as its underlying I/O object, but this is
just an internal detail. The exposed API is totally ALSA-free.
--p
This archive was generated by hypermail 2b28 : Fri Apr 27 2001 - 02:44:31 EEST