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: Brad Ford <email@hidden>
- Date: Tue, 20 Mar 2007 11:21:14 -0700
On Mar 19, 2007, at 1:24 PM, Michael Dautermann wrote:
Hi Jeff, thanks for following up!
On Mar 19, 2007, at 12:45 PM, Jeff Moore wrote:
My audio plug-in should be selectable without having live audio
streams (or a device connected) though, right?
Can you explain a bit more about what you mean?
I see how that's a confusing choice of words on my part.
The more succinct question I should have asked was: "if somebody
in DTS were looking at my plug-in code, they should be able to
select & open the plug-in via the sequence grabber even though they
wouldn't have my unique device connected nor would they necessarily
hear modulating audio, right?"
My plugin claims an AudioDeviceID in its Initialize function. At
the same time, the plugin also claims two AudioStreamID's (one for
the left and one for the right channel) and marks those two stream
id's as created via AudioHardwareStreamsCreated. And it's through
those id's the "DeviceGetProperty" and "StreamGetProperty"
functions are presumably being called.
I totally agree with Jeff that you should be using HALLab as your
primary bring-up and validation tool. Your device needs to work
right in HALLab before it has a prayer of working in Sequence
Grabber. That said, here's what's going on in SG. Sequence
Grabber's audio channel has api to get a list of available devices.
Each device is described as a CFDictionary of key/value pairs. To
compile this dictionary, SG queries your audio device for a number of
properties. As currently implemented (that's a big caveat -- all of
this is subject to change in the future) you'll get asked:
1) AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyModelUID, ...)
2)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDeviceUID, ...)
3)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDeviceNameCFString, ...)
4)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDeviceManufacturerCFString, ...)
5)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyTransportType, ...)
6)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDeviceIsAlive, ...)
7)AudioDeviceGetPropertyInfo(deviceID, 0, true,
kAudioDevicePropertyStreamConfiguration, ...) // here's it's just
looking for a non-zero mNumberBuffers
8)AudioDeviceGetPropertyInfo(deviceID, 0, false,
kAudioDevicePropertyStreamConfiguration, ...) // here's it's just
looking for a non-zero mNumberBuffers
9)AudioDeviceGetProperty(deviceID, 0, false,
kAudioDevicePropertyHogMode, ...)
10)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDeviceIsRunningSomewhere, ...)
(if you have input streams)
11)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyPlayThru, ...)
12)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDataSource, ...)
13)AudioDeviceGetPropertyInfo(deviceID, 0, true,
kAudioDevicePropertyDataSources, ...)
If you have data sources on your input side, you'll additionally be
queried for:
14)AudioDeviceGetProperty(deviceID, 0, true,
kAudioDevicePropertyDataSourceNameForIDCFString, ...) // for each one
15)AudioDeviceGetProperty(deviceID, 0, false,
kAudioDevicePropertyDataSource, ...)
16)AudioDeviceGetPropertyInfo(deviceID, 0, false,
kAudioDevicePropertyDataSources, ...)
If you have data sources on your output side, you'll additionally be
queried for:
17)AudioDeviceGetProperty(deviceID, 0, false,
kAudioDevicePropertyDataSourceNameForIDCFString, ...)
But again...this is just one usage case. Logic, Garage Band,
QuickTime Player, etc will all have different calling conventions and
perhaps a different set of properties they care about. HALLab does a
good job of exercising most if not all properties, so it can torture
test your audio device better than any of the above named apps.
-Brad Ford
QuickTime Engineering
If you plug-in is currently not exposing any AudioDevices, then
the Sequence Grabber won't see anything. If you plug-in is
exposing an AudioDevice without any AudioStreams, then I imagine
that most apps would ignore your device.
If it's something else, you'll need to get into more detail about
what you are doing and what you expect to see happen.
What I was expecting to happen was that the Sequence Grabber
successfully selects my Audio Hardware Plugin and starts reading
off the streams (at which point, I could fire up a separate pthread
to start processing incoming audio data).
Or do I need to be firing some kind of "Process" (i.e. stream
processing) thread (or callbacks) to stuff audio bytes into my
output mBuffers even before the sequence grabber attempts to select
my plug-in?
thanks again,
_______________________________________________
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
_______________________________________________
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