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: "B.J. Buchalter" <email@hidden>
- Date: Sun, 20 Dec 2009 02:46:11 -0500
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.
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?
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).
Best regards,
B.J. Buchalter
Metric Halo
http://www.mhlabs.com
_______________________________________________
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