Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: pe syys 24 1999 - 19:42:12 EDT
On Fri, 24 Sep 1999, Benno Senoner wrote:
[...]
> > There's one trick that *could* be done at virtually no cost though -
> > sending the same buffer to multiple recipients. What I'm getting at is this: If
> > the DSP <-> GUI communication is based on the two sending events directly to
> > each other's event ports, the automation system could tap data from those
> > communication paths by scanning the GUI -> DSP buffers for input, and sending
> > it's output to both the GUI and the DSP code.
>
> Yes this seems ok to me,
> bt I want a generalized system where every other process can be the
> "automation".
I was thinking along those lines as well. However, I think that calls for a per
event routing system in the engine - which would probably have a lot more
overhead than a "sender selects target per event" system.
Not sure though - there's certainly a lot to keep in mind here...
> In short, I wat that my own process is able to get parameter-changes
> notifications from the engine, and is allowed to send parameter-changes to any
> plugin. (with immediate reflection on the GUI sliders, other
> automation-recorders etc).
Yes, that's basic. That's what the client/server/plug-in architecture is all
about in this case, IMO.
> what about the following scenario:
> sequencer1 continuously changes the cutoff frequency of a LP filter-plugin,
> the GUI slider moves reflecting the changes.
Ok. Sequencer 1 somehow (directly or indirectly) sends events to both the
filter plug-in, and the GUI element (which is in fact a plug-in as well).
> sequencer2 records the automation parameters.
It could request to become another recipient of all events sent to the filter
plug-in. That is, another port to recieve a pointer to the same event buffer.
(Can you see the problem that's been on my mind for a while? What if seuencer2
would request event buffer mirroring from multiple sources? Yep, either the
engine gets to merge buffers - which is a lot more expensive than passing over
a pointer - or sequencer2 has to use one extra event port for each port it
wants to mirror. Not sure yet if this really matters, or if it would be less
expensive to pay somewhere else to solve this...)
> If the user moves the GUI sliders manually sequencer2 can record the data too.
Just another mirror... However, I'd like some nice way to keep track of what
belongs where. You get events from the GUI, and from the DSP code... Will this
be a frequently seen scenario that can be handled by the engine in an optimized
way? Seeme like it, but I might be wrong. Is the solution smart use of
mirroring and merging, where the engine handles setting it up, so that
plug-ins and clients won't have to worry much about it?
(I'll probably find a much better solution after having spent countless hours on
figuring out the details of this one! *hehe*)
> > Not a hardware problem, but what I have in mind isn't really networking - it's
> > about building clusters using 100 MB or gigabit ethernet with RTLinux RT
> > communication drivers. More like extending connecting the machines into
> > something like a huge SMP box, than building a network...
>
> Ok in a dedicated enviroment running at 100Mbit or 1Gbit , if there is no
> additional random network traffic, IMHO using simple UDP/IP with SCHED_FIFO
> processes you can reach a <20-30ms latency for your needs.
Perhaps I should just set up the Dual box as well, and play some with my 100
Mbit network... It's just that I have way too much to do already.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST