Subject: Re: [linux-audio-dev] sound API libraries, servers, etc. (fwd)
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: Fri Apr 20 2001 - 20:19:02 EEST
Hi!
Well, this discussion briefly left the list (why doesnt lad set default reply
to things ;), anyway, here's Pauls reply to my reply:
-----Forwarded message from Paul Davis <pbd_AT_op.net>-----
Subject: Re: [linux-audio-dev] sound API libraries, servers, etc.
From: Paul Davis <pbd_AT_op.net>
>Really? I've right now only seen the CSL announcement, I made together with
>Tim Janik ;).
there was one on LAD, one on alsa-devel; each for different
libraries. or so i thought.
>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.
here's the problem: you end up with an app that goes through CSL, then
through aRts then through ALSA. this seems kind of crazy to me.
>I can see that people might want to make alsalib also server-aware, so that
it already is, but it has its own server too :(
>aRts *does* offer in-process clients. You are right about
>multichannel hardwar e 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 agree. i'd like to see that happen, but i'm honestly not sure how
much time i can spend on it. i think that we talked loosely about it
before, and there are things like threading and RT issues that don't
seem trivial to solve. the whole reason for aes was simply to meet the
needs that aRts (currently) does not. then again, everyone has their
own "special" reason, right ? but then again, it does seem to me that
its quite possible that you really do need two different server
architectures, one for "generic multimedia" and one for low latency,
multichannel "commercial" situations. i'm not sure about this.
the other thing about AES is that its trivially easy to use the
AudioEngine object within a dedicated application, thereby allowing
you to use the same API whether you're using a server or not. this is
made possible by the fact that it *only* supports in-process clients,
thus making this kind of thing totally obvious.
can aRts be used in this way ? it seems to me that being able to do
this is is a nice way to get people to use the API.
anyway, the main thing that i would need to provide aes-like
functionality from within aRts is a per-channel read/write model. i
wish i had already had more time to look at aRts - would this be hard
to do?
>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
esound is dead (especially if the GNOME guys are going to work with
you), and besides, its really just OSS+LD_PRELOAD.
gstreamer is not really a server architecture, AFAIK.
maia is not a server architecture in any sense.
so things are not as bad as it looks. the problem right now is:
OSS
ALSA
aRts
<modest>aes</modest>
WrapperLibraries
if we can merge aes and aRts, and OSS has to die anyway, then we're
left with
ALSA
aRts
WrapperLibraries
and I know what the obvious choice is from that list ... (assuming we
can get all that we want from aRts). clearly, that would really be
aRts (using ALSA) :)
--p
-----End of forwarded message-----
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : Fri Apr 20 2001 - 20:40:03 EEST