Hi W.
So, I've downloaded the AU and looked at it, and this is a bug in your
code and you should fix this before you release the audio unit. I'm
posting the response to the list in case other people have this problem.
Here is what the struct looks like:
typedef struct AudioUnitParameterInfo
{
char name[52];
CFStringRef unitName;
UInt32 clumpID;
CFStringRef cfNameString;
AudioUnitParameterUnit unit;
AudioUnitParameterValue minValue;
AudioUnitParameterValue maxValue;
AudioUnitParameterValue defaultValue;
UInt32 flags;
} AudioUnitParameterInfo;
In a 32bit world, it will look exactly the same in terms of the bytes
it uses to the way this struct looks in Leopard or Tiger. In the 64bit
case, the struct will be a different size than in the 32 bit case,
because the pointers of the contained members are of course 64bit
pointers, not 32bit, so the offsets of clumpID for instance, will be at
a different byte offset than in the 32bit case.
In AUBase, you have this method (to fill in the struct):
static void FillInParameterName (AudioUnitParameterInfo& ioInfo,
CFStringRef inName, bool inShouldRelease)
{
ioInfo.cfNameString = inName;
ioInfo.flags |= kAudioUnitParameterFlag_HasCFNameString;
if (inShouldRelease)
ioInfo.flags |= kAudioUnitParameterFlag_CFNameRelease;
CFStringGetCString (inName, ioInfo.name, offsetof
(AudioUnitParameterInfo, clumpID), kCFStringEncodingUTF8);
}
This is safe for both 32 and 64 bit architectures.
In auval, it gets the name of the parameter 52 bytes into the struct,
which is where unitName is defined to be. It will of course read either
a 32 bit or 64 bit value from that location depending on which arch is
being executed.
I think that what you are doing is something different with the name of
the parameter (perhaps you are only storing a 32bit value for the unit
name)?
There is some history to the way we have dealt with this struct, and so
if you compiled against an older version of the headers, or had written
your own method for storing the unitName, then you might not have this
in a completely safe manner for dealing with both 32 and 64bit archs.
Thanks
Bill
Quoting William Stewart <email@hidden>:
This isn't a known issue. Can you send me the AU so that I can have a
look at it?
On Jan 22, 2010, at 2:07 PM, Blue Cat Audio Dev wrote:
Hi,
I have been trying to validate 64 bits AU plugins for Logic
9.1, but auval crashes as soon as one of the parameters uses
a Custom Unit (kAudioUnitParameterUnit_CustomUnit set and
non-NULL unitName). You can see the log and stack below.
If the unitName field of the AudioUnitParamInfo struct is NULL
for all parameters, auval does not crash anymore and the
plugin can be validated. This problem does not occur for our
32 bits plugins, and the 64 bit plugin is running fine in
logic despite this auval crash (even the generic "controls"
view works, displaying appropriate units).
I have tried both static and dynamically allocated CFString for
unitName, it has no effect: auval keeps crashing.
Is this a known issue? Is there anyway to avoid this problem
apart from suppressing custom units from the parameters?
Regards,
W.
Blue Cat Audio
=> auval log extract:
--------------------------------------------------
PUBLISHED PARAMETER INFO:
# # # 9 Global Scope Parameters:
validation result: crashed validation
--------------------------------------------------
=> stack
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff803a2b40 CFRelease + 112
1 auvaltool 0x0000000100005582
0x100000000 + 21890
2 auvaltool 0x0000000100005af6
0x100000000 + 23286
3 auvaltool 0x000000010000cf63
0x100000000 + 53091
4 auvaltool 0x00000001000015de 0x100000000 + 5598
5 auvaltool 0x0000000100001c7f 0x100000000 + 7295
6 auvaltool 0x0000000100000c1c 0x100000000 + 3100
_______________________________________________
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