Re: Programmatic Aggregate Device issue on Intel Mac, not always completing initialisation?
Re: Programmatic Aggregate Device issue on Intel Mac, not always completing initialisation?
- Subject: Re: Programmatic Aggregate Device issue on Intel Mac, not always completing initialisation?
- From: Dan <email@hidden>
- Date: Wed, 9 Jul 2008 23:21:39 +0100
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.
Dan
2008/7/9, Jeff Moore <email@hidden>:
> '!size' == kAudioHardwareBadPropertySizeError
>
> This means that you aren't passing the proper size to the property. It
> appears that the reason why is that you didn't notice that the value of
> kAudioHardwarePropertyDeviceForUID is actually an
> AudioValueTranslation structure:
>
> from <CoreAudio/AudioHardware.h>:
> @constant kAudioHardwarePropertyDeviceForUID
> Using an AudioValueTranslation structure, this
> property translates the input
> CFStringRef containing a UID into the AudioDeviceID
> that refers to the
> AudioDevice with that UID. This property will return
> kAudioDeviceUnknown if
> the given UID does not match any currently available
> AudioDevice.
>
>
>
>
>
> On Jul 9, 2008, at 8:29 AM, Dan Stowell wrote:
>
>
> >
> > >
> > > > OK, thanks. I added the following to the above code, at the point
> > > > marked "point at which to add the delay":
> > > >
> > > >
> > > > CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1,
> false);
> > > > address.mSelector =
> kAudioHardwarePropertyDeviceForUID;
> > > > err = AudioObjectGetPropertyData(coreaudioPlugin,
> &address,
> > > > sizeof(CFStringRef), CFSTR("SCAggregate"), &aggregateSize,
> > > > &aggregateID);
> > > > if (err != kAudioHardwareNoError)
> > > > {
> > > > scprintf("get kAudioHardwarePropertyDeviceForUID
> error %s\n",
> > > > (char*)&err);
> > > > return false;
> > > > }
> > > >
> > > >
> > > > It results in the following error in all configurations:
> > > >
> > > > get kAudioHardwarePropertyDeviceForUID error ?ohw
> > > > so I guess I'm doing something wrong...? Thanks for any further
> advice.
> > > >
> > >
> > > As it's name implies,
> kAudioHardwarePropertyDeviceForUID is a property of
> > > the system object, not the plug-in object. That's why you are getting
> the
> > > error here.
> > >
> >
> > Thanks. Sorry to be dense, but I used "kAudioObjectSystemObject"
> > instead of "coreaudioPlugin" in the above and it must not be right
> > because it doesn't work - produces error "zis!". Does it need to be
> > written differently than:
> >
> > err =
> AudioObjectGetPropertyData(kAudioObjectSystemObject,
> &address,
> > sizeof(CFStringRef), CFSTR("SCAggregate"),
> > &aggregateSize, &aggregateID);
> >
>
>
>
> --
>
> 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
>
--
http://www.mcld.co.uk
_______________________________________________
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