Re: more AU info and plugins (should be "I need to share data")
Re: more AU info and plugins (should be "I need to share data")
- Subject: Re: more AU info and plugins (should be "I need to share data")
- From: Marc Poirier <email@hidden>
- Date: Sat, 21 Jun 2003 08:16:37 -0500 (CDT)
Hi Philippe. Your findings are interesting, but I think you misunderstood
my point to an extent. I wasn't making recommendations of how AUs should
be hosted, I was making recommendations of how AUs should be designed in
order to safely operate regardless of how any hosts are implemented.
If you use pointer access between your audio and GUI components, then you
are making a few assumptions (that the two components exist in the same
address space, that there will not be more than one GUI component for the
audio component, etc.). If your assumptions are correct in a given
situation, than everything will be fine, but if your assumptions are
incorrect in a given context, then your AU won't work correctly and
possibly crash. But if you don't make these assumptions and instead
follow the model of AU design properly, then your AUs will work in any
situation. That's what I was trying to say.
So as far as the separate address spaces example goes, maybe it's not an
efficient thing for hosts to do today, but maybe it will be soon or later,
who knows...
Marc
On Sat, 21 Jun 2003, Philippe Wicker wrote:
>
Nice initiative Marc :-))
>
>
While reading some of your additions I could read this in the
>
"Communicating between AU and edit view instances" topic:
>
>
"I would also discourage passing pointers between your audio component
>
and your GUI component [snipped] Another issue is that there's no
>
guarantee that a GUI component will exist in the same address space as
>
the audio component".
>
>
I'd like to make some remarks about this last statement.
>
>
As in every matter, there are pros and cons.
>
The pros: if host and components code are "segregated" in different
>
address spaces, a crash in any of the components will leave the host
>
and the other components in a state where they can continue on working.
>
The cons (yes, this is the only "pro" I can figure out):
>
1- A remote procedure call is not resource free. For my professional
>
activities I had to bench the time it takes to synchronize 2 processes.
>
The time for a process A to switch to a process B and back to process A
>
(which is the basic sequence when executing an RPC) is about 35
>
microseconds (best case) on a 550 MHz PowerBookG4 and about as much on
>
a PowerMac DP867 (it costs more on a dual processor because
>
synchronizing processes also implies synchronizing the 2 processors).
>
The actual overhead would be greater because of the preparation of
>
parameters for the call and for the return (aka
>
marshaling/unmarshaling). We could live with such an overhead, but I
>
hate consuming resource when it is not absolutely needed. There's
>
however a 2nd "con" which is IMO much stronger.
>
2- There are situations where several instances of the components will
>
have to work on the same data. I'll take an example. A "sampled
>
instrument" based MusicDevice instance may have to load, say, a grand
>
piano. Another instance may have to load a bright piano. The user wants
>
to edit both instruments. And it happens that both instruments are
>
based on the same set of samples. A good "memory management" would be
>
to load the set of samples only one time and to share it between both
>
AUs and both AU-GUIs components (such programs may be very big, there
>
exists a free sampled piano (from Akai) which takes more than 200
>
MBytes !!!). Beside, any editing on the GUI side could not be instantly
>
propagated to the AU side if components have separate address spaces.
>
Of course, workarounds are possible. Those components may open a POSIX
>
shared memory and do their work in that SHM. Not so simple and not as
>
flexible as using the process memory.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.