Re: Audio Device Property Caching in Snow Leopard?
Re: Audio Device Property Caching in Snow Leopard?
- Subject: Re: Audio Device Property Caching in Snow Leopard?
- From: Jeff Moore <email@hidden>
- Date: Sat, 24 Oct 2009 11:35:55 -0700
On Oct 24, 2009, at 12:26 AM, AI Developer wrote:
Hello Jeff,
Thank You! Thank You! That was indeed the problem.
BTW, is this change in behavior(SnowLeopard not having it's own
thread by default) documented somewhere?
Not at the moment.
Also, I do not see any mention of being able to set
kAudioHardwarePropertyRunLoop to NULL in the documentation for the
property.
At http://developer.apple.com/mac/library/documentation/MusicAudio/Reference/CACoreAudioReference/AudioHardware/index.html
it says:
-----------
kAudioHardwarePropertyRunLoop
The CFRunLoopRef the HAL is currently attaching all of it's system
notification handlers to. By default, the HAL will create and manage
it's own thread for this job. Clients can set this property to tell
the HAL to use a thread of the client's choosing. The caller is
responsible for releasing the returned CFObject.
-----------
That's my bad. I apparently forgot to update the headerdoc comments
for this property. Please file a bug!
Will setting kAudioHardwarePropertyRunLoop to NULL not cause any
problems for Leopard and Tiger(even though that is the default
behaviour)? I'm trying to determine if I should make the code
version specific.
No. It won't cause any problems, but it is not necessary.
Also, is there a comprehensive list of changes between Leopard and
SnowLeopard for CoreAudio/HAL/AUHAL that we can go through to make
sure that other things are not broken in our programs for Snow
Leopard?
Not to my knowledge.
Thanks.
Devendra.
Jeff Moore wrote:
On Oct 23, 2009, at 6:35 AM, AI Developer wrote:
I've still not been able to get a handle on this problem, but I
had a thought, perhaps someone can help me on this:
Is it possible that the GetProperty will not reflect the change
until the SR change notification is handled by the HAL's
notification handler.
Yes. The HAL isn't omniscient. It needs to be informed by the
driver and other outside entities when things change.
And if the notification handler's run loop source has been added
only to the primary thread (which is also making this call), the
state will not get updated until the notification handler gets a
chance to do it's work?
This is also correct. The HAL's handles all the interesting
notifications using the run loop specified by
kAudioHardwarePropertyRunLoop. If this run loop is not getting time
to run, the HAL will not be able to get any information from the
outside world.
By default, kAudioHardwarePropertyRunLoop points at the process's
main thread on SnowLeopard. You can set
kAudioHardwarePropertyRunLoop to any run loop in your process that
is definitely going to get time to run. If your process lacks such
a run loop, you can set kAudioHardwarePropertyRunLoop to NULL which
tells the HAL to run it's own thread for notifications (which was
the default prior to SnowLeopard).
AI Developer wrote:
Hi,
Does Snow Leopard cache audio device properties, and satisfy
calls from the cache?
I've run into a very wierd problem when trying to change the
Sampling Rate of a device on SR.
If I set the SR, and then query the SR back, I do not get the new
value - ever, as long as the application instance is running!
Here's some sample code that demonstrates the problem:
-------
err = AudioDeviceSetProperty(currentID, NULL, 0, 0,
kAudioDevicePropertyNominalSampleRate, propSize, &srToSet);
if (err == kAudioHardwareNoError)
{
Float64 currentSR = 0.0;
propSize = sizeof (currentSR);
err = AudioDeviceGetProperty(currentID, 0, 0,
kAudioDevicePropertyNominalSampleRate, &propSize, ¤tSR);
if (err == kAudioHardwareNoError)
{
std::cout << "\tResultant Nominal Sampling Rate: " << (int)
currentSR << " Hz.";
}
}
-------
If srToSet is differet from the current rate, and I execute this
code, the value coming out of the GetProperty is not as expected.
Note that at the same time, the SR has been changed properly
(Audio MIDI Setup shows the new value as soon as the SetProperty
succeeds). It's just that the process that has invoked the
SetProperty shows the wrong value.
This only happens on 10.6, not on 10.5.
Am I doing something wrong here?
Thanks.
Devendra.
_______________________________________________
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
--
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