Re: what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
Re: what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
- Subject: Re: what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
- From: Jeff Moore <email@hidden>
- Date: Thu, 15 Mar 2007 17:51:26 -0700
On Mar 15, 2007, at 5:32 PM, Michael Dautermann wrote:
Hi Jeff!
Thanks for taking the time to look into this and respond.
On Mar 15, 2007, at 3:59 PM, Jeff Moore wrote:
I've been reading this and so far nothing unusual seems to be
happening except I think you need to clarify how you implement
kAudioDevicePropertyStreamConfiguration. You say:
"In the AudioBufferList structures I am returning from the
DeviceGetProperty calls, I set mNumberBuffers to 2 channels,
mNumberChannels to 1, mDataByteSize to 512 bytes *
sizeof( float ), and mData to NULL."
Do you mean that you are making an ABL that looks like this:
or like this:
-------------------------------
| mNumberBuffers == 2 |
-------------------------------
| mBuffers |
| mNumberChannels == 1 |
| mDataByteSize == 2048 |
| mData == NULL |
-------------------------------
| mNumberChannels == 1 |
| mDataByteSize == 2048 |
| mData == NULL |
-------------------------------
The first one is what it sounds like you are describing. This is
incorrect whereas the second one is the correct one for describing
your device with two mono streams.
The second (correct) one is what is being returned.
Ah. Good. It wasn't clear.
if you aren't already doing so, you should instrument all the entry
points of your plug-in.
The reason why is that the API boilerplate in the HAL will try to
verify the existence of a property by calling your plug-in's
ObjectHasProperty or XXXXGetPropertyInfo methods before getting or
setting it's value. It's entirely possible that the SequenceGrabber
is looking for a specific property that you aren't implementing
currently. But you wouldn't know it without instrumenting all of
the plug-in entry points.
Do you mean I should make sure all the selectors for
DeviceGetPropertyInfo and StreamGetPropertyInfo get handled?
I mean adding printf's that display every call into your plug-in and
what those routines returned...
In my debugging output, I print out all selectors that come in
through those two API's.
...which appears to be what you are doing.
The only selectors that my DeviceGetPropertyInfo implementation
doesn't handle are 'pmas' and 'namr' ( I don't see these defined in
any header files under /System/Library/Frameworks, so I am not sure
what to do with them or if they matter ).
The 'pmas' selector is unknown to me. I don't know what that one is
for. The 'namr' selector is an ancient selector that returns the non-
localized (that is, English) name of the device as a C-string.
At any rate, I can't imagine that either of these properties are what
is causing the SG to return that error. One puzzling thing about this
to me is that the HAL always returns error codes that are 4CC's or are
kernel errors. Both of these would look more or less like very large
positive integers. The error you are getting,
kAudioUnitErr_InvalidPropertyValue, is specific to the AudioUnit
stuff. To get that error, I think would involve some problem with the
Sequence Grabber talking to it's instance of the HAL output AU.
If this is something that you can package up and send to us, you might
want to do that in the form of a bug report.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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