Subject: Re: [linux-audio-dev] Re: AudioServer Standard?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe syys 24 1999 - 09:59:30 EDT
On Fri, 24 Sep 1999, David Olofson wrote:
> On Fri, 24 Sep 1999, Stefan Westerfeld wrote:
>> > Of course I don't know what exactly you want to do in Audioality and how,
> > but from the discussion and from the webpage it seems to me like the
> > goals you have are very close to the goals of aRts. On the other hand, aRts
> > is under development about two years, and has many of the things you say
> > you want to achieve already. And more.
>
> Yes, I think we're trying to do about the same thing. Unless there's some
> very fundamental difference between our projects, there are basically two ways
> to go, I think:
>
> 1) Keep developing Audiality, as a new engine built from scratch, learning from
> the experience with aRts and other systems, and supporting the latest concepts
> from the ground up.
>
> 2) Drop the Audiality engine development, and instead concentrate on the new
> plug-in API, porting aRts to RTLinux to cover the sub 3 ms latency range, and
> other similar efforts.
>
> Question: What would result in the best solution in the long run?
If you ask me,
David seems to be one of the best "Mr.optimizer" (speed/efficiency/low-mem
footprint optimizations) around in the linux-audio arena,
maybe because he is doing control-processing at work,
and audio/DSP stuff is some sort of control processing.
I know almost nothing about arts, but audiality will certainly be optimized
as much as possible.
Of course audiality is still "vaporware" compared to arts.
I'm more for the 2nd solution:
in in the mean time you should use arts, and we could take the good ideas
from arts, and when arts reachs an usable state, provide the arts-compatibility
layer.
>
> > 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 (which is why this topic came up),
> > etc.
> >
> > Of course, it isn't perfect, and there are quite a few things that could
> > be done a lot better. But it is a program you can install, play with,
> > change a few lines, recompile, and immediately see the effect. Of course,
> > if you want to have a new plugin API and a new signal flow scheduler,
> > you change a bit more. But still you can keep the whole framework, GUI
> > stuff, flow graph stuff, etc., which won't care about that kind of
> > things.
>
> That's kind of what I had in mind... Perhaps I could use aRts as a starting
> point for the implementation of Audiality? It could save time for me, and might
> also result in some useful new that can be ported back to aRts until Audiality
> is mature enough to use.
I agree.
>
> > So why don't you just consider working on aRts? It's open source and your
> > ideas/code is always welcome. I think linux should try to solve problems
> > once, right, together and then build on what is there. Finally, that also
> > seems to have happened for Desktops, where we have now Gnome and KDE, and
> > most people just joined one of the projects, so we have two very nice
> > solutions here.
> >
> > Thats what should happen for audio, too.
>
> Yes, I agree, and we certainly need to get rid of this chaos of different
> plug-in APIs and incompatible engines. What I'll do depends on how different
> aRts is from my Audiality plans... I want the plug-in and client APIs to be
> flexible, efficient and powerful enough for most Linux audio developers to use,
> or it won't be much point. I'm aiming for something more like an OS audio
> infrastructure than a specialized music/audio engine.
That's the main point because I'm opting for audiality,
since the core is very simple, and of course very efficient (I agree about the C
over C++ speed advantage (see linux-kernel folks) ,
but it is 100% extensible. That means no functionality limitations,
just hook up the additional functionality you need.
I hope that we do not run into ego-clashes or something.
(on one wants to drop his own engine).
Joining forces is IMHO very important for the succeeding of a decent audio API
on Linux.
But sometime building a system from scratch produces better results than
adapting existing ones.
See Cygnus' Ecos Embedded modular RTOS,
they developed an embedded OS from scratch, instead of downsizing Linux.
And indeed Ecos is almost impossible to beat in terms of memory-footprint.
(Can run in a few KBs on a flashrom)
Consider the fact that Audliality will be designed from principle with RTLinux
in mind (but you can run the engine as user process too).
That means timing performance better than most dedicated HW solutions.
I will play a little with arts to get a better vision of the engine.
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST