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: Mon, 19 Mar 2007 14:06:55 -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.
In this case, I would expect that applications would see a device with
two streams.
You can confirm or deny this by using HALLab, which is one of the
sample projects in our SDK. HALLab basically tries to be a GUI onto
the raw HAL API. So, you can see all the properties and their values
that your device is exposing. Often, this can expose where your API
conformance is a bit lacking, so it's a good place to make sure your
device is working as you expect before trying it out with the rest of
the system.
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?
I think you need to step back and start with the basics of creating a
proper HAL plug-in. It's not at all clear to me that you have done
that yet. As I mentioned above, HALLab is a great way to make sure
things are working in accordance to how the system expects your device
to behave. HALLab also will give you a better idea about how the HAL
works because it's pretty clear that you aren't too sure about that
either.
Once you have something that works in HALLab, then you can expand your
testing to APIs that are layered on top of the HAL, such as the
Sequence Grabber.
--
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