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

[Juhana Sadeharju <kouhia nic funet fi>]

>From:   Stefan Westerfeld <stefan@space.twc.de>
>
>Not really. aRts requires really tight timing for tasks like full duplex
>audio processing, hard disk recording, realtime midi synthesis (I don't

Well, Arts is an audio engine (as well as have flow network builder) and
not just an application which has a quick hack of audio routines.

I have expected that at most we could cowork by making a common audio
engine (flow engine, disk service, audio card service, timings and
syncronizations, etc.). Then everything else around the core engine
would be different (CORBA, etc.).

Arts would use the core engine as library (as would Audiality use) but
the common applications would use the engine only via engine API.
Arts as an audio server in KDE would offer applications the similar
audio possibilities than Audiality.

I think there is no need to have only one engine around but we could
copy best parts of each's audio system for making a pretty good common
core engine.

For the above reason, I would like to see a detailed description about the
flow system of Arts and a list of features it lacks currently.

>For instance it will integrate really nicely into the next version of
>kooBase (which will be called Brahms), has really decent flow graph
>management, audio server functionality

Are you aware of Galan? Its network editor look pretty good but I have not
got into details. I remember Arts (previously Ksynth) had some very odd
looking network builder -- is the same GUI still in Arts?

>So why don't you just consider working on aRts? It's open source and your
>ideas/code is always welcome.

We should rewrite the core engine and not just submit code to the current
engine. We should write it in C not in C++.

Yours,

Juhana