Subject: Re: [linux-audio-dev] sound API libraries, servers, etc.
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Apr 20 2001 - 15:47:05 EEST
>And as a pure but nevertheless funny and interesting coincidence, aRts is
>just about being integrated into Gnome. Now THAT may be a small revolution,
>if it gets real.
>
>Besides, don't you think that there are two flavours of doing audio ?
>
>A dedicated app which must have the BEST performance without any droupouts,
>and in that way
>a raw api like alsa is perfect (I was thinking about HDrecording, live
>performance), and a desktop server for notifications, music, games, ...
>which may have droupouts but should be integrated and simple to use. I think
>they serve different purpose. Of course, having both would be delightful,
>but I think aRts is not optimized enough to be said lightweight right now,
>but maybe I'm misinformed, given the pace of KDE and its focus on 2.2
>multimedia enhancements.
this is why i wrote aes. i don't know enough about the internal
structure of aRts to know if it could be modified to support the kind
of functionality supported by aes.
either way, i would rather see the Linux audio world evolve as a
series of cooperating, data-sharing applications. there are many
people in the windows/macos worlds who want to know why cubase can't
record the audio output from <some-softsynth> or related questions.
that means that the applications have to give up the idea of direct
access to the hardware and leave that to a "server". as long as the
"server" offers a way for clients to be in-process, and runs its audio
thread in such a way as be able to use the smallest h/w latency
settings without dropouts (i.e RT_FIFO scheduling, mlock(), no system
calls except poll(2)), i'm willing to write my applications to work
with such a system, and i've "offered" AES as my own implementation of
such a system.
--p
This archive was generated by hypermail 2b28 : Fri Apr 20 2001 - 16:05:58 EEST