Subject: Re: [linux-audio-dev] a port/buffer proposal
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Tue May 22 2001 - 23:12:30 EEST
On Tue, 22 May 2001, Jim Peters wrote:
> > * when does all this stuff happen?
> > ----------------------------------
> > in a naive model, it happens on every engine cycle.
> >
> > in a more sophisticated model, the memory buffers are requested
> > whenever the signal graph is modified. the rest of the stuff happens
> > on every engine cycle.
>
> The `naive' method might be necessary: I was thinking about how we
> could optimise the original single-thread approach to work well on a
> dual-processor machine - having two real-time threads both working
> simultaneously through the graph, each taking the next available job.
> This means that the precise order of execution depends on how long
> individual plugins take - processor A might execute three plugins in
> the same time that processor B executes just one. This means that
> which buffers become free at what time varies according to execution
> times. This is likely to apply if we are now moving towards a
> multi-process-compatible scheme. In the original single-thread
> method, everything could be decided beforehand (buffer addresses,
> detailed plugin run-order, etc), but not now.
>
I don't think this threading model is going to work very well. The normal
graph sort produces a single list of 'jobs' (really function calls) with,
most often, the next job depending on the previous (usually for data).
The precise order of execution is very important. Also, regardless of
whether a single-thread/multi-thread/multi-process model is chosen
everything can and should be determined ahead of time. The two models
that seem likely to work to me are:
1) Sort the graph into several 'job' lists - each would start with plugins
that have no data dependencies (i.e. have output only) and go until there
is a data dependency. At this point this list will 'merge' with the list
that satisfies the dependency reducing the number of possible active
threads by 1. This is done until the entire graph is sorted. Any number
of threads can be active up to the maximum number of lists at any given
time.
2) I have seen this model called the 'leader/follower' model and seems the
most promising to me. The graph is sorted into a single 'job' list like a
single-threaded model. Several worker threads are created waiting for
data from the soundcard. As soon as data is available a thread is
dispatched to execute the job list. This means that more than one thread
can be in the graph with _different_ data. Of course, the threads must be
kept in order which is potentially a problem with non-deterministic
graphs, but this is overall simpler and seems to have more potential for
real concurrency. Notice, also, that the amount of processing that can be
done in parallel is limited by how deterministic the graph is rather than
data depencies. There are graphs that cannot be executed in parallel at
all using the first model.
I want to mention again that I think all of this can be an implementation
detail invisible to plugins with a simple enough api. Also, using
multi-something does not automatically garuntee that anything will happen
in parallel.
Karl
>
> Jim
>
> --
> Jim Peters (_)/=\~/_(_) Uazú
> (_) /=\ ~/_ (_)
> jim@ (_) /=\ ~/_ (_) www.
> uazu.net (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
>
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| mambo.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Wed May 23 2001 - 18:41:32 EEST