Re: [LAD] [EPAMP] an effect plugin API for media players:?anyone interested?

On Tue, Jun 03, 2008 at 11:22:15PM +0200, Wolfgang Woehl wrote:

> Paul Davis:
>
> > but think about what this actually means in practice: it means that
> > your chaining logic is actually responsible for plugin
> > instantiation (and destruction). a given plugin "unit" might have
> > 1, 2 or more actual plugin instances within it. but if plugin
> > instantiation is being done from within the chaining logic, how
> > does it share code that the host might use that overlaps with this
> > in some way?
>
> My gut reaction is to think that it's a bad thing if there were
> overlaps in handling connections; that there should be 1 plumber in
> the house to handle all the connections a signal route could imply.
>
> The plumber would know from a chain members's properties whether it
> needs to bring in jack logic, inter-plugin logic ... The house would
> only ask for new chain members, not set them up. Refactor?

I had the same 'gut reaction' when reading Paul's post.
But it's by no means a simple thing. Remember that the
plumber can't do his work in Jack's thread (since he has
to do non RT-safe work), and 'users' (the Jack thread)
will try to use the things being plumbed behind his back
unless they are told not to.

I've had similar problems in some clients that allow the
user to reconfigure all or part of the processing in a more
invasive way than just change a parameter value. The solution
I adopted amounts to:

1. the main thread receives an event saying that processing
   has to be reconfigured (e.g. a user clicking a button).

2. It changes state and sends a message to the processing
   thread to bypass the processing (producing silence if
   there's no other alternative).

3. This message is seen in the next callback. The processing
   code changes state and sends a message to the main thread
   saying it's now safe to modify the processing chain.

4. The main thread receives this message, reconfigures the
   processing code, and when ready sends a message to Jack's
   thread to resume normal processing.

5. This message is seen in the next callback. The processing
   code changes state and sends a message back the the main
   thread.

6. The main thread receives this message and changes state
   to accept new reconfiguration requests.

This can be simplified, e.g. the messages to the RT thread
can just be flags that are set by the main thread and tested
in the callback, and if the main thread has a periodic wakeup
the same can be done with the replies. And most of this can
be hidden inside the processing 'object' that is shared by
the two contexts. But even then it remains somewhat invasive,
requiring state management at both ends, and it won't be easy
to hide all of it into a simple-to-use 'support library'.

Which in the end means that anyone wanting to do this sort
of thing should really understand what is involved, even if
he/she doesn't have to write all the code to implement it.
Which in turn means that it's probably a futile exercise to
try and make it 'easy' to would-be programmers wanting to
write the ultimate media player without even having an hint
of how complex such a thing can be.

Ciao,

-- 
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev