RE: Cocoa IN Audiounit
RE: Cocoa IN Audiounit
- Subject: RE: Cocoa IN Audiounit
- From: "Jeremy Jurksztowicz" <email@hidden>
- Date: Fri, 13 May 2005 19:05:41 +0000
{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{
This kind of sounds to me like you are breaking a cardinal rule that
we strongly advise developers about... and that is to have a good
separation between the AU's implementation and the view. As much as
possible the only information that you should be sharing between the
two is data - definitely not objects, "this" pointers, etc - as all
of this assumes that your AU and its view is always going to run in
the same address space. That is not a good assumption.
{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{
Uh-oh. This sounds like bad news. To be more specific I am sharing the Model part of my MVC cocoa interface with the audiounit. The audio unit is using the model to render it's data (no worries, all realtime safe), and the view is accessing the same model instance to present its data. The data is not really presented via the audiounit paramater interface. Are you saying that I should only share float/UInt32/raw data? Ouch, how about callbacks? What the audiounit really has to do is determine how to build a C++ interface object (class InputInterface) based on the specifics of the model classes.
For example, in my audiounit components initialize or reset:
(note that the objC code is in it's own compilation unit AudioCocoaHook.mm, and is called as plain C++ code from the AudioUnitImpl.cpp)
// AudioCocoaHook.mm
auto_ptr<InputInterface> AudioCocoaHook::createInterface () {
// Actually creating model object IN the audio unit component.
// MYAudioIO * processorIn is a member variable of this class.
processorIn = LoadAudioProcessorFromFile(filePath);
if([processorIn isKindOfClass:[MYAudioInput class]])
{
return auto_ptr<MYAudioInput_CppInterface>(new
MYAudioInput_CppInterface(
[processorIn renderCallback], (void*)processorIn));
}
}
void* AudioCocoaHook::modelAddress ( )
{ return (void*)processorIn; }
// AudioUnitImpl.cpp
ComponentResult MyAudioUnit::Initialize ( ) {
myInput = _audioCocoaHook->createInterface();
return AUEffectBase::Initialize(); // << Is this necessary?
}
Then in the RenderBus:
if(myInput)
myInput->pullAudio(ioBufferList, inNumberFrames, inTimeStamp);
And in GetProperty:
case kMYAUProperty_CocoaModel:
memcpy(outData, _audioCocoaHook->modelAddress(), sizeof(void*));
return noErr;
Except in initialization(resetting) only the C++ interface is used. But the view and the audiounit must refer to the same model object (which is created IN the audio unit and then passed to the view, you already stated that assuming they are in the same address space is not a good idea). So basically, is it possible to safely share model objects, or do I need to copy raw memory around? And if I create the model object in it's own dynamic library and share that instance between the unit and view, do I still need to worry about address space issues? How about if I add callbacks for all the models functions that the view needs to access, as private properties?
What I am understanding is that the view and audio unit has to communicate only with the standard AU interface and passing raw memory (possibly across address spaces). As of yet I do not have access to Tiger, so I can't look up the examples you suggested.
Thank you,
Jeremy Jurksztowicz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden