[linux-audio-dev] [forward from stefan westerfeld] servers, sound apis, etc.

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

Subject: [linux-audio-dev] [forward from stefan westerfeld] servers, sound apis, etc.
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Apr 20 2001 - 20:07:31 EEST


stefan sent this just to me by mistake. hopefully he'll forward
my (mistakenly) private reply to him.

--p

------- Forwarded Message

Date: Fri, 20 Apr 2001 18:35:29 +0200
From: Stefan Westerfeld <stefan_AT_space.twc.de>
To: Paul Davis <pbd_AT_Op.Net>
Subject: Re: [linux-audio-dev] sound API libraries, servers, etc.

   Hi!

On Thu, Apr 19, 2001 at 07:58:33PM -0400, Paul Davis wrote:
> in the last couple of days, i've seen a couple of announcements of new
> libraries designed to "abstract" various audio APIs.

Really? I've right now only seen the CSL announcement, I made together with
Tim Janik ;).

> i want to rant for a moment. apologies in advance if i step too
> heavily on anyone's toes.
>
> i just don't get the idea of these libraries. IMHO, there is only one
> sensible kind of audio API library that should be developed beyond the
> so-called "native" ones, and thats a *SERVER* API to allow multiple
> apps to collaborate, cooperate and possibly, though not necessarily,
> communicate, all in a device and device-API independent fashion.
>
> [...]
> * aRts
>
> - comprehensive server
> - full collaboration and sharing
> - incorrect support for high end devices
> - out-of-process clients
also:
- - in-process-clients (you can load a client as component into the server)
- - low latency as design goal
- - highly modular, not necessarily limited to "audio" (i.e. midi events and
  things like that)

> so what is the point of the wrappers?
>
> well, there is a very obvious point, and that is allowing people to
> write applications that can be compiled in the presence of different
> audio device APIs.
>
> but...i really strongly and strenuously do not believe that
> new libraries are the way to do this. the way forward is for
> applications to use existing server architectures that take care of
> all that low-level device access crap, and leave them free to do their
> thing without paying any attention to those details. One way or
> another, we're fundamentally talking "plugins" here, though at a
> different level, mostly, than LADSPA offers.

Well, I know that it would be nice to leave the hardware access thing to
a server. But sometimes, people will tell you "I don't want a server to
deal with my audio data". Especially this could be true for embedded devices
like mobile phones, PDAs, and so on. So in that case, people might want the
guarantee that not a single of their CPU cycles or bytes in the memory is
used for a sound server. So if they still want audio but can afford loosing
interoperability with other audio apps, and so on, they could write their
application using CSL.

On desktop machines, it would use aRts, on PDAs it would use OSS directly.
It's not the primary thing I am interested in, but it's good to have the
possibility open.

I can see that people might want to make alsalib also server-aware, so that
you can use your alsalib application with aRts for instance. I would be really
happy if somebody did this. If CSL gets obsoleted by alsalib in the long run,
well, why not. But for now, I think CSL is a good thing to have.

> if aRts could adopt the model that AES uses for h/w access and offer
> in-process clients, i would be happy to recommend aRts for
> everything.

aRts *does* offer in-process clients. You are right about multichannel hardware
access, though. Currently nobody working on aRts is doing heavy multichannel
work. I know that this would be nice to have, and if you (or somebody else)
wants to work on that, please do so. It shouldn't be too hard to get it going.

I think working together on this in some way is better than ending up with
different incompatible solutions. Having six servers, for instance one
provided by aRts, ALSA, esound, aes, gstreamer, maia would be for sure
worse than coordinating things now.

   Cu... Stefan
- --
  -* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
 

------- End of Forwarded Message


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

This archive was generated by hypermail 2b28 : Fri Apr 20 2001 - 20:27:37 EEST