Re: [linux-audio-dev] Re: timing issues in a client/server enviroment

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: timing issues in a client/server enviroment
From: Benno Senoner (sbenno_AT_gardena.net)
Date: la loka   09 1999 - 19:02:03 EDT


On Sat, 09 Oct 1999, Paul Barton-Davis wrote:

>
> Specifically, I want people to be able to use a variety of different
> applications that might provide the services advertised by the API;
> the situation with GNOME and KDE where there is "standard" not just in
> terms of an API (and runtime library) but also the actual applications
> that must be running is something I don't wish to support. It might be
> useful for people who need handholding with their desktop, and want
> their "you have mail" messages playing back while they listen to a
> real audio clip. But its not OK for those of us who want to do more
> dedicated and serious audio work.
>
> So yes, I think the development of a standard API, a library, and one
> or more sample implementations is a great idea, but please don't
> anyone go off and think they are writing "the Linux Sound System".

I agree on the fact that apps should be able to do their own pugin hosting,
but sooner or later we will need some engine which allows routing and
integration of simultaneously running audio apps,
or audio software software vendors will not be very motivated to port
their apps to linux and audio software users will not switch to linux
for serious audio work.
What do you say when users will begin asking:
"why am I unable to record the gigasampler pcm output in my cubase
or drive the reaktor synth from my preferred sequencer, and recording
the result on my HD recorder ?
sooner or later we will need "the linux soundsystem".
An app can choose to not use our api by using legacy /dev/dsp , /dev/midi,
but it will be feed through our engine.
If you don't run the engine, legacy apps wouls still function.

An OS that provides only PCM and MIDI drivers is not suitable
to provide a powerful and flexible DAW enviroment.

Quasimodo is a nice app with many functions, but it's still a monolithic app,
and my foobar wave editor can't use your 24db lowpass filter with a simple
API call.

My idea is an engine ( userspace or RTLinux) , which handles the whole thing.
It could be similar to quasimodo, but in form of an engine, with flexible
routing, sample accurate evet processing, syncing etc.
Quasimodo would become a client to the engine, and it would open up
infinite possibilities, (driving quasimodo from sequencers, feed quasimodo's
output to HD recorders etc.)
Maybe you can get some of these features by using appropriate hacks
but then you end up as in the windoze case.
"you can't run A+B while C is running etc)

If we create a good audio API, well designed , with no (or as little as
possible) conceptual flaws , I'm very confident people will begin to use it,
and especially audio software vendors will be much more motivated to
port their software to linux if they know that linux provides
an enviroment with excellent intergration features.
Paul the keyword is "integration", and I think many people are not very
satisfied with windozes integration between audio apps,
(see for example Seer Reality monopolizes the DirectX PCM audio,
that means if you want to play your mp3 on your 2nd soundcard, you can't)
and if we are able to come up with a good standard,
I'm sure that many will have valid reasons to switch.

regards,
Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST