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 16:07:32 -0700
One other thing: 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.
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:
-------------------------------
| mNumberBuffers == 2 |
-------------------------------
| mBuffers |
| mNumberChannels == 1 |
| mDataByteSize == 2048 |
| mData == NULL |
-------------------------------
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.
On Mar 14, 2007, at 4:14 AM, Michael Dautermann wrote:
On Mar 12, 2007, at 4:54 PM, Brad Ford wrote:
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.
Does your device have input streams? Setting the above property
will fail if the device is not capable of capturing audio. The
Sequence Grabber determines this by querying it for its streams on
the input side.
Hi Brad (and anyone else who knows Audio Hardware Plugins),
My device does indeed have input streams. I claim audio stream IDs
in my plugin's Initialize function, mark them created, and when I
attempt to select my audio plugin using the Sequence Grabber, I see
a number of things firing within the plugin.
When our app does the QTSetComponentProperty call, here is the
order of what I see firing in my plug-in:
DeviceGetProperty: muid
DeviceGetProperty: uid
DeviceGetProperty: lnam
DeviceGetProperty: livn (I list my device as alive)
DeviceGetProperty: slay (this call is asking about my two input
channels, L&R, and I return an AudioBufferList for each of those
channels)
DeviceGetProperty: slay (this call asks for stream information
about output channels, for which I have zero)
DeviceGetProperty: oink
DeviceGetProperty: slay (my input channels are being queried again)
DeviceGetProperty: thru
DeviceGetProperty: stm# (I set the stream list returned to the IDs
created in my initialize function)
StreamGetProperty: sfmt (one for channel 0 of the first stream ID,
this would be the left channel of my device)
StreamGetProperty: sfmt (the second stream ID; this would be the
right channel of my device)
It's after these last StreamGetProperty calls (with the
kAudioDevicePropertyStreamFormat property id) that
QTSetComponentProperty returns the error of -10851.
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.
Once the processing callback actually starts up, I'll have a
separate AudioBufferList to handle the data being sent over by my
device.
Is there something else the sequence grabber might be looking for
after that long sanity check of the stream? does there need to be
data (or something that's not null) in the mData fields of the
AudioBufferList?
If this is getting a little too in depth or esoteric, let me know
and I can take it over to DTS.
--
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