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: Thu, 10 Jul 2008 11:09:39 +0100
Thanks - making the aggregate public does prevent the
CFRunLoopRunInMode problem. However, the CFRunLoopRunInMode trick
doesn't fix the original problem, so I've removed it again.
Having poked at this for a while I suspect it could be a mutex-lock
issue or similar. Our GUI application applies a pthread_mutex_lock
before executing a command, then pthread_mutex_unlock afterwards. The
CLI version doesn't use a mutex while booting, so it's a definite
difference between the two environments. Is it possible that this is
what's preventing the aggregate device from starting its IOProc? If
so, maybe the solution for us will have to be to launch the boot
process as a new thread rather than synchronously.
When I was using CFRunLoopRunInMode, I saw that the pause was allowing
GUI refresh code to kick in which was then requesting the same mutex
lock, hence causing a lockup. With CFRunLoopRunInMode removed, the
debugger shows this for the state of one of the threads:
#0 0x90009cd7 in mach_msg_trap
#1 0x90009c38 in mach_msg
#2 0x9082d227 in CFRunLoopRunSpecific
#3 0x9082ca42 in CFRunLoopRunInMode
#4 0x91469356 in HALRunLoop::OwnThread
#5 0x91469171 in CAPThread::Entry
#6 0x90024227 in _pthread_body
If I'm reading this right it says the HAL is calling
CFRunLoopRunInMode and therefore maybe falling into the same hole.
So I suspect we need to use a separate thread, but grateful for any
additional thoughts. Thanks for the advice you've given on this.
Dan
2008/7/9 Jeff Moore <email@hidden>:
> It seems like you are hitting the bug I was referring to about newly created
> aggregates seeming to disappear. Also, I just remembered that there is
> another bug where private aggregate devices will also sometimes completely
> vanish into the ether. I suspect that this is what is killing you now so if
> you made a public aggregate, you should get farther.
>
> On Jul 9, 2008, at 3:21 PM, Dan wrote:
>
>> 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.
>
>
>
> --
>
> 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