what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
- Subject: what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
- From: Michael Dautermann <email@hidden>
- Date: Fri, 9 Mar 2007 16:09:01 -0800
Hi all,
The answer to this should be staring me in the face but it's escaping
my notice.
I'm putting together a new Audio Hardware plugin. I'm very thankful
for the JackRouter project (THANKS Stéphane!) but oh how I wish there
were more sample code & projects to rely on.
Under DeviceGetPropertyInfo, I set the size of the
kAudioDevicePropertyDeviceUID property to CFStringRef and for
DeviceGetProperty, I'm returning my device uid properly using:
*outString = CFStringCreateWithCString(kCFAllocatorDefault,
"MyNiftyDevice:0", CFStringGetSystemEncoding());
I can see these properties and the UID of my plugin just fine when I
examine it under HALLabs.
But when I try to set the Sequence Grabber in my application to pick
it up (via QTSetComponentProperty, using the same format as WhackedTV):
err = [self setPropertyWithClass:
kQTPropertyClass_SGAudioRecordDevice id:
kQTSGAudioPropertyID_DeviceUID size: sizeof(uid) address: &uid];
this fails with a kAudioUnitErr_InvalidPropertyValue.
Anyone have any ideas off the top of their head what I might be missing?
p.s. as an aside, WhackedTV passes an NSString in for the UID and
that NSString's "sizeof" byte count doesn't match the byte count for
the [ NSString length ]. Should I be surprised this works for Apple
sample code?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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