Re: Some more questions about sample rate notifications
Re: Some more questions about sample rate notifications
- Subject: Re: Some more questions about sample rate notifications
- From: Jeff Moore <email@hidden>
- Date: Mon, 14 Jan 2008 13:06:18 -0800
On Jan 14, 2008, at 2:34 AM, Stéphane Letz wrote:
For various reasons our program cannot adapt to sample rate changes
done directly on the device by the user. Thus if the user tries to
change the SR of the device currently used, we try to change back to
our current SR (we have seen that GarageBand used the same strategy).
This is a fine opportunity to remind folks that device settings belong
to the user, period. Apps should not be doing what you are doing. It
is inherently brittle and more often than not goes against the wishes
of the user in the first place.
We use the following code:
1) Add a listener for kAudioDevicePropertyNominalSampleRate change
2) In this listener we do:
// Stops the AUHAL
err = AudioOutputUnitStop(driver->fAUHAL);
if (err != noErr)
...
// Read the new SR
err = AudioDeviceGetProperty(driver->fDeviceID, 0,
kAudioDeviceSectionGlobal, kAudioDevicePropertyNominalSampleRate,
&outSize, &sampleRate);
if (err != noErr)
...
// If needed change it back to our current SR
if (sampleRate != driver->fSampleRate) {
sampleRate = driver->fSampleRate;
err = AudioDeviceSetProperty(driver->fDeviceID, NULL, 0,
kAudioDeviceSectionGlobal, kAudioDevicePropertyNominalSampleRate,
outSize, &sampleRate);
if (err != noErr) {
...
}
// Finally restart the AUHAL
err = AudioOutputUnitStart(driver->fAUHAL);
if (err != noErr)
This strategy does not always work, particularly when a aggregate
device is used:
That's because you are racing the rest of the system and potentially
any application that is doing the same thing you are doing.
In fact, I once watched what I'll term a "death spiral" between two
apps as they competed to see who could set the sample rate the
fastest. It was really quite amusing. App A would set the sample rate
and App B would change it back which caused A to set it again, etc.
Both apps SPOD'd and required me to force quit them.
You definitely don't want to do that to your users, but you will by
pursuing this strategy.
1) It works if the user changes SR in the aggregate device itself
(using Audio Midi Setup for example). We see the SR changing to the
wanted value then go back to the current SR and the AUHAL restart
correctly.
Yup. That's what racing does for you. It wouldn't surprise me if it
turned out to be the case that you were trying to slam the sample rate
while the hardware was still in the middle of changing to the new
rate. This sort of race can't be won, which is why you shouldn't be
doing it in the first place.
2) it does not work if the user changes SR in one of the device
(input or output) used in the aggregate device:
- if done on the "aggregate input device" , the (global) SR of the
aggregate device seems to correctly switch back to our current SR
but then the AUHAL does not restart correctly: no err but the device
audio callback is never called again.
- if done on the "aggregate output device", the aggregate output
device completely disappear from the aggregate device (seen in AMS)
and obviously nothing works correctly again.
It sounds to me like you are ending up with one very confused
aggregate device. In fact, it also wouldn't surprise me if the
instance of AUHAL you are using thinks it is not actually attached to
any devices any more after all the notifications have shaken out.
You'd have to debug this more on your end to know for sure why your
instance of AUHAL is refusing to start.
Doing the exact same test with GarageBand (that is changing the SR
in the aggregate or in its input or output part) show the *same*
problem, up to the point when GB cannot play again.
This problem is quite annoying since some programs (we have seen
that with Max/MSP) possibly restore a device configuration state
when they change the SR of a device used in an aggregate device,
thus completely stopping our program.
So, what you are saying is that because some other app thinks it owns
the hardware and is slamming settings that it is causing trouble for
your app? Really? I never would have guessed that something like that
could happen =)
This is exactly the sort of chaos that will ensue when apps start
thinking they own the hardware settings and among the reasons we give
the advice we do about hardware settings (even to Apple apps like
GarageBand). Repeat after me: you cannot control the format of the
hardware absolutely. You have to be able to adapt to what it gives
you. There is no middle ground where you can slam the sample rate like
you are trying to do.
--
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