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: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka   10 1999 - 00:38:05 EDT


>> yes it is. in fact, its precisely why Paris, ProTools and the rest all
>> work under Windows :) oh, ok, these are not flexible enough. i
>> agree. but this has to do with inter-app communication, not
>> *necessarily* access to the device drivers.
>
>Actually people are used to an all-in-one enviroment provided by
>a specified hw/sw platform.
>For some people the all-in-one hw/sw can provide enough
>flexibility to perform the needed tasks.
>But providing alll needed features for all possible users on
>a single monolithic application is just impossible.
>This is why I am for a modular design.
>In fact actually there is no OS providing this modular DAW enviroment
>out of the box (I don't know if BeOS has some of these features).

its the plugin API that makes this kind of issue go away, and its why
people working with the existing DAW systems don't mind - they feel as
if their system is *not* monolithic - it can run stuff from Waves, TC,
Antares and many others ... "yes, but its just one program" "we don't care!"

being able to add stuff to a program with a truly standard API makes
it non-monolithic. if the program does nothing without plugins, then
its pretty close to the server model you propose.

>Just as you can run 10 instances of GIMP, you should be able to run
>10 instances of Cubase, as long you do not overload the CPU,
>since in the latter case there are realtime requirements.

why would i want to do that ? why does anyone want to run 10 instances
of the GIMP, or even 2 for that matter ? its less efficient, its eats
CPU time, colormaps etc, and buys you *nothing* ! but perhaps i don't
use it enough ... yes, these observations are true for multi-user
hosts, but i don't think thats the context we're operating in.

>Yes, braindead design is one issue, but ofter the limiting factor is the
>host's API, which doesn't make any assumption about concurrent execution
>of several apps.

right, so we have to get the API right.

>> two context switches per delivery of data is just silly, for some things.
>
>actually the number is much lower:

          [ ... example elided ... ]

>As you see:
>5 clients running + 1 audioserver = 6 context switches, seems pretty ideal eh
>?
>:-)

no! its true that your overall throughput is better, and the
"audio data sent per context switch" is better, but: for any *given*
client, the situation is *much* worse than if it were managing the
device drivers itself.

>Assume: we run 5 soft-synths + audioserver with 1ms fragment granularity:
>we need 6 context switches ( max 60-75usec).
>Which is about 5-7% CPU overhead.
>If you increase the fragment size to 3ms , the overhead goes down to 1%.
>Davids sample accurate event system would still provide exact timing,
>and at 3ms the latency would still be much better than on other OSes / hw-boxe
>s.

if these numbers really turned out to be true, it would work for
me. but i have a feeling that it won't.

>there are 2 solutions:
>1) the app implements his own "server" which is rather silly since you are
>reinventing the wheel.
>
>2) the app calls our audio server, but then we are in my proposed case.

3) the audio server is a library, which any application can link to.
   then we have the best of all possible worlds!

--p


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