Some more questions about sample rate notifications
Some more questions about sample rate notifications
- Subject: Some more questions about sample rate notifications
- From: Stéphane Letz <email@hidden>
- Date: Mon, 14 Jan 2008 11:34:00 +0100
Hi,
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).
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:
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.
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.
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.
Thanks
Stephane Letz
_______________________________________________
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