[prev in list] [next in list] [prev in thread] [next in thread] 

List:       arts
Subject:    Re: KSynth feedback
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1998-07-30 18:07:49
[Download RAW message or body]

   Hi!

> >This approach would most certainly be optimal in terms of
> >CPU usage. However, the analysis would have to be pretty dam smart to
> >figure out the best way to implement a given configuration. In the 1-by-1
> >scheme each component can be a black box. In the analysis scheme I get the
> >feeling that the analysis program needs detailed knowledge of each
> >component.
> 
> I'm not sure but I think the only needed info would be the implicit
> delay we allow in the whole system.
> 
> Please let me ask about the current system: does the system allow
> a convolution module, implemented with FFT, needing 512 input samples
> before anything can be outputted? I suspect the answer is no, and then
> your modules cannot truelly be black boxes, right?

Currently, the system assumes that every module can perform it's
calculations with no delay. This makes sense in an realtime environment
I suppose.

So if you wanted to implement your 512-BY-512 FFT module, you could only
to the following:

Your module would output the data 512 samples after getting it (and being
a 512 samples delay module besides being a FFT module). So it would be
sure to always have 512 bytes in a buffer when calculation is needed.

To get nice mixing, you would need to use delay modules on the
signals that did not go through the FFT module.

> I have figured out my own flow system earlier but have not completed it.
> Between each module I have an "arc". "arcs" are ring buffers for storing
> the signals which cannot be processed immediately.
> 
> For example, if the convoluted signal and the original signal are mixed
> together, then we would need a 512 sample length arc for both the original
> signal (just before the mixing module) and the convoluted signal (just
> before the mixing module).
>   Otherwise, without the arc, we would have to mix the signals immediately,
> causing an implicit delay of 512 samples between the orig and the conv
> signals, and the mixing module should be able to receive 512 samples at
> once from the convolution module.

I thought about that. The question is, how do you determine when a module
needs to be scheduled. And how do you avoid that modules that have no
input signals do not overflow the arc they output their data to?

The idea might not be too bad, if you

 - make the modules decide, whether they would like to do calculations,
   while giving them access to the status of all their input & output
   arcs

 - schedule the modules just randomly around

 - impose a limit onto the modules, so they can't write more than x
   signal values to an output arc, for x values of about 32 or so.

   (Yes, it doesn't make your 512 samples FFT module possible then,
   but it will run realtime quite nice).

The question is how efficient can such a system be - when it would
be possible to run this way and still be near optimal scheduling
performance, I'd like it. It doesn't sound complicated to implement
either.

I am not sure though, whether in a large synthesis model with many
modules all the arcs would be filled with data, making the overall
delay actually a little large anyway (n*32 samples, where n is the
amount of arcs between signal source and Synth_PLAY module).

> In a system containing arcs, the module can have more freedom.
> But realtimeness causes problems: there is still a 512 sample delay
> at the output (but not between the orig and conv signals!) which causes
> that changes in convolution module parameters (if any) is heard
> after 512 samples. Right?

Yes, 512 samples are quite heavy. Since KSynths midi support is based on
a realtime approach, playing midi files would be broken as well, I guess.

At least with the current algorithms.

The KSynth communication model currently looks like this:

1. synth_server starts. It enters the CORBA idle loop (which is basically
   a select or something like that), the Synthesizer object is being provided
   to the outside world.

2. [...] various communication with ksbuild [...]

3. The user selects execute model. The model description is sent to the
   synth_server from ksbuild.

4. synth_server leaves its idle loop and builds up the modules. Some of them
   (Synth_PLAY) return file descriptors they want to get watched.

5. synth_server drops to idle loop again

6. Some time later some file descriptors need food. (Normally the audio
   output fd). synth_server leaves its idle loop.

7. synth_server executes 64 cycles of the modules (while scheduling one
   turn to each module, then the next turn to each module, and so on).

   The audio output fd gets some data.

8. The action starts at point 5 again.

Only in the idle loop, KSynth is being able to receive events from the
outside world, such as midibus events or a Stop-request. Later, there
will be the point where the GUI elements can contact KSynth as well.

This is because the CORBA calls from the outside world never interrupt
running methods, they can only be processed from the idle loop.

   Cu... Stefan

[prev in list] [next in list] [prev in thread] [next in thread]