On Thu, 13 Jul 2000, Benno Senoner wrote:
[...]
> So assume we run Evo and Cubase:
>
> to save some typing I will introduce:
> AT= audio thread , MT = midi thread , DT= disk thread
>
> The soundserver will fire up 3 threads for handling AT,MT and DT.
>
> Assume you run Evo alone:
>
> at each iteration the:
> audiothread calls EvoAT() ( which returns after one audio fragment got
> processed)
> diskthread calls EvoDT()
> midithread calls EvoMT()
>
> This is basically the same as my program does, except that the soundserver
> loads the .so module and calls the 3 procedures at each iteration. The
> overhead is basically zero. (one function call more)
>
> Now we start up Cubase and the Cubase callbacks are added to the soundserver
>
> now at each iteration the:
> audiothread calls EvoAT(); CubaseAT();
> diskthread calls EvoDT() ; CubaseDT();
> midithread calls EvoMT(); CubaseMT();
>
> As soon as the CPU usage does not go over 100% (the audio thread is the most
> sensible one), both apps will run perfectly in parallel and PERFECTLY SAMPLE
> ACCURATE without any scheduling overhead.
> (and the audio device sharing problem is solved as well since only the
> soundserver access it)
>
> In my opinion this is the way to go, since multithreading can become VERY heavy,
> especially when we have 700usec fragment cycles (like in the disksampler case).
>
> what do you think ?
Yep. All we need is that perfect API that makes this virtually
transparent to the application programmer, and most importantly, to
the user. :-)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
