Re: [linux-audio-dev] Re: AudioServer Standard?

[Benno Senoner <sbenno gardena net>]

On Thu, 23 Sep 1999, Stefan Westerfeld wrote:
> 
> On Mon, Sep 20, 1999 at 10:10:39AM -0400, Havoc Pennington wrote:
> > On Sat, 18 Sep 1999, Stefan Westerfeld wrote:
> > > 
> > > Currently, there were some discussions on kde-core-devel regarding what
> > > should be the audio server for KDE 2.0. I suggested aRts (well, I wrote
> > > it, so I think it's a great thing... ;), another solution would be
> > > KAudioServer2 and the third solution would be ESD.
> > > 
> > 
> > We are looking for an ESD replacement or at least a rewrite, and
> > apparently it has some technical shortcomings (don't ask me for details, I
> > don't know anything about sound). I _definitely_ want to have KDE and
> > GNOME using the same sound system.
> 
> Yes, that would be just perfect.

Agreed, but I think the definitive audio/multimedia interface will be
Audiality designed from the ground up.
The API is still in the design stage, since we are thinking about
how to implement the most flexible, performant sound engine which scales from
games to highend pro-audio stuff.

Of course KDE and GNOME need a standardized audio sever now,
therefore audiality can't help now, since there is no code yet.
I think a good solution is to support /dev/dsp virtualization like esddsp does.
That means old audio applications will still work, while new apps can take
advantage of the high performance API, which uses for example less membandwidth
using smart IPC techniques like shmem etc.

Later when audiality will be fully fuctional we could provide a compatibility
layer for esd or arts-enabled sound apps.
Right, David ?

> Of course, the web pages are mainly focused on explaining how aRts is used
> as synthesizer, since thats what most people will do with it right now. It
> doesn't cover too technical details, too. 
> 
> So I tried to make a technical feature list here, hoping some insight in
> why I think aRts is the right thing for an audio server (or if you like,
> audio framework, audio middleware, multimedia subsystem or something like
> that).

It shares many concepts with audiality, but I don't know anything about the
design.

> 
> 
> == Overview: aRts and its features
> 
> + the core idea: signal flow
> 
>   aRts is a signal flow system. That means, that it is based on the assumption
>   that multimedia tasks generally can be described as flow graphs with
>   components. Arts manages the signal flow between the components.

the concept is ok.

> 
>   Currently the signal flow is assumed to happen always realtime. Further
>   enhancements of aRts could also handle non-realtimed signal processing.
> 
> + implementation as CORBA server
> 
>   On the other hand, aRts is designed to be a server. That is, it will run,
>   and different applications will tell aRts what things to start for signal
>   flow evaluation.
> 
>   That means that multiple applications share the same signal flow system.
>   You could for instance play an mp3 (with a standard, arts compliant mp3
>   player) and record the result with your hard disk recording system which
>   also runs on the same aRts server.

The audiality idea is similar, you can route audio/multimedia events sources to
arbitrary destinations

> > + modularity
> 
>   The components that are running inside the signal flow evaluation are
>   implemented as small modules that are linked to the server (a shared-
>   library interface would be no problem for that).
> 
>   So if you need a new wave form, a new filter, a new effect, a new sample
>   format etc. you simply write a new module.

also called plugins
:-)

> 
>   Through the signal flow system, it is also possible to draw a signal
>   flow (aRts calls that a structure), and reuse that as module in other
>   signal flows.

supporting multiple instances of the plugin is a required feature for a decent
plugin system.

> 
>   aRts uses very small components, and schedules them with very little
>   overhead. So you don't have some processes which do signal processing
>   and connect them with TCP streams (which would really cosume lots of 
>   CPU power).

Yes calling the Process() function for each plugin is the fastest way to do it,
since you have no process scheduling overhead.
All plugin APIs like VST do this to achieve maximum performance.

> 
>   Instead, all modules are running in one adress space. They are connected
>   by ring buffers, which allows you to run 300 modules at a time on a
>   PII-350.
depens how much CPU each plugin uses.
Try to run 300 instances of Waves Trueverb on a PII350.
:-)

> 
> + network transparency
> 
>   Since aRts uses CORBA for almost everything, it is network transparent.
>   On the other hand, some audio server functionality that has been
>   implemented in aRts use TCP to transfer the signal for instance from your
>   external (non-arts-module-like) mp3 player to aRts. This TCP stuff is
>   also network transparent.

tenwork transparency is ok, but we need to separate the things,
that means if source and destination are on the same machine,
use IPC/shmem to exchange data,
if not then use sockets or so.
But Corba seems a bit slow to me for a high performance event system.

> 
> + synthesis implemented GUI independant
> 
>   All the synthesis modules aRts uses (such as Synth_STD_EQUALIZER) don't
>   know anything from the GUI at all. They use no Qt and no whatever. They
>   are only connected to the GUI through the same signal flow mechanisms
>   that are used for everthing else

Of course the DSP stuff must be separate from the GUI stuff, and the engine and
the GUI should comunicate through a fast event system.

> 
> Well, thats a brief summary - the best thing to do to see more is to
> download a version and play a little with it. And of course - please ask
> anything that isn't clear after reading this mail.

Quite clear your mail.
I will check out arts , seems nice to me.
> 
>   Cu... Stefan
> -- 

tschuess,
Benno.