Thanks for the correction. I'm on the PPC machine at the moment, and
seeing some strange behaviour, seemingly triggered by the
CFRunLoopRunInMode delay. Here's what happens:
The first thing I did was change the re-fetching of the aggregateID to
the following:
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false);
s = CFStringCreateWithCString(NULL, "SCAggregate",
kCFStringEncodingUTF8);
AudioValueTranslation translation2 = {&s, sizeof(s), &aggregateID,
aggregateSize};
size = sizeof(translation2);
err = AudioHardwareGetProperty(kAudioHardwarePropertyDeviceForUID,
&size, &translation2);
CFRelease(s);
scprintf("Audio device ID is %p\n", aggregateID);
if (err != kAudioHardwareNoError)
{
scprintf("get kAudioHardwarePropertyDeviceForUID error %s\n",
(char*)&err);
return false;
}
When run, this doesn't throw an error, but gave me an error later on
(the error being "!obj" (bad object reference) thrown by the very next
call, to kAudioAggregateDevicePropertyFullSubDeviceList). I also see
that although the original aggregateID was not a null pointer, the
re-fetched aggregateID is a null pointer.
However, I then discovered that the "!obj" error can be triggered
*purely* by the call to CFRunLoopRunInMode(). If I comment out *all*
of the above, except the CFRunLoopRunInMode() call, the "!obj" error
still appears.
* If I pull the delay value down to 0.01 seconds then the behaviour
goes away - the engine boots correctly, creates its aggregate and can
use it.
* If I push the delay value back up to 0.03 seconds or more then the
behaviour comes back (!obj every time).
* At delay of 0.02 seconds, the behaviour is intermittent: sometimes
boots successfully, sometimes !obj.
* At long delay (0.5) it's still constantly giving !obj.
* With the CFRunLoopRunInMode() call removed entirely, it boots
successfully.
* With the CFRunLoopRunInMode() call removed and the re-fetching added
back in, it boots successfully.
(More specifics: in the tests above it's the CLI audio engine I'm
referring to, with my firewire box and the builtin audio as the
devices to aggregate. OS is 10.4.11)
Note that if I include the delay but don't include the re-fetching,
then aggregateID is not a null pointer (it's the same value as in the
successful trials, 0x112), so that's not the cause of the "!obj" in
that case. However, in the case of delay-and-refetch, the null pointer
obviously isn't pointing to the device.
Any clues? I'm puzzled by the fact that the delay seems in itself to
worsen the situation.