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: Philippe Wicker <email@hidden>
- Date: Sat, 21 Jun 2003 12:58:01 +0200
On Saturday, June 21, 2003, at 05:31 AM, Marc Poirier 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.
Cheers,
>
Hi. Just a quick message to mention some stuff I've put out there that
>
might be of interest and/or useful to some:
>
>
I finally went through a bunch of old mails I've written and added some
>
hopefully useful stuff to the CoreAudio Swiki:
>
http://www.mat.ucsb.edu:8000/CoreAudio/
>
I also appended some info to some other people's contributions (I hope
>
that they don't mind).
>
>
I also just wanted to mention that I've made AU GUIs for most of the
>
Destroy FX AUs at this point. I've done 9 out of 11. The remaining
>
two
>
(Skidder and Monomaker) are having their interfaces redesigned
>
currently,
>
so they probably won't be done anytime soon. So, for any of you
>
looking
>
for more plugs to test in your host or more example code or just some
>
super hot effects or whatever: http://destroyfx.org/audiounits.html
Philippe Wicker
email@hidden
_______________________________________________
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.