Re: Difference in behavior between 10.5 and 10.6 in Logic
Re: Difference in behavior between 10.5 and 10.6 in Logic
- Subject: Re: Difference in behavior between 10.5 and 10.6 in Logic
- From: Jeff Moore <email@hidden>
- Date: Sun, 20 Dec 2009 09:44:28 -0800
On Dec 19, 2009, at 11:46 PM, B.J. Buchalter wrote:
>
> On Dec 19, 2009, at 2:11 PM, Jeff Moore wrote:
>
>> If the problem happens in Logic but not in HALLab, the implication is that there is something particular to what is going on in Logic that is causing the issue. I don't know what an "I/O plug" is, how it makes the measurements you are describing or how hit interacts with Logic, so I can't really offer any specific advice given the information at hand.
>
> Hard to say exactly where it is happening in Logic -- I am kind of guessing there.
>
> The Logic 9 I/O plug is a plugin that can be inserted in the mixer and allows the user to route the plug's input out to a physical I/O on the driver, and then route a physical input from the driver to the plug-in's output. The intention is to allow the user to patch in external processing into a channel strip in the logic mixer. The Logic 9 version of the plugin includes a "ping" mechanism that sends out an impulse and then measures how long it is before it comes back on the input. If the measured latency is equal to the logic buffer latency+2*(driver offset)+(driver input latency)+(driver output latency), then the plugin reports a latency offset of 0. If the latency is longer or shorter, then the plugin reports the offset from 0, and that is used in Logic's latency compensation algorithm so that the track comes back in from the physical I/O and any processing aligned with the other strips in the mixer.
Ah. So it's part of Logic and not some independent thing.
>> That said, the main change to the HAL in 10.6 that has caused the most mischief for apps was the change to the handling of the HAL's notification thread. Prior to 10.6, the HAL spawned it's own thread for this job by default. In 10.6, the HAL was changed to use a process's main thread for the job. The net effect is that if the main thread gets busy or it's run loop doesn't get tasked at all (which is the case in a lot of command line tools), the HAL won't be able to receive notifications from the driver in a timely way.
>>
>> Your description of the issue sounds like it might fall into this category. But it's hard to say for sure as Logic lacks the other, more visible problems I have seen in apps that have been adversely affected by this change. For example, an app that has been hit badly by this change will have something like a sample rate change either take a really long time to complete or just cause the app to completely hang depending on how the app handles things.
>
> Thanks for the info. Why was that change made?
Probably 999 out of 1000 apps that initialize the HAL do not to pay the cost of keeping an extra idle thread laying around all the time. For the ones that do, the API was already present to give them control over that thread anyway.
>> At any rate, filing a bug is always a good first step in any case.
>
> Done. Radar: 7487949
>
> I have determined that this can be easily reproduced with a slightly modified version of the AudioReflectorDriver (included in the Radar), and it does not happen in 10.5, so it is not specific to our driver -- it appears to be an issue in the HAL or Logic. Perhaps a race between the notification and the restart of the audio engine in logic (including the capture of the latency values from CoreAudio).
Thanks for the report!
--
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