Re: Recommended way to handle suspend/resume on notebooks
Re: Recommended way to handle suspend/resume on notebooks
- Subject: Re: Recommended way to handle suspend/resume on notebooks
- From: Jeff Moore <email@hidden>
- Date: Tue, 13 Oct 2009 11:40:26 -0700
You should always feel free to report bugs.
It might help matters if you were able to simplify things in your set-
up to eliminate variables since it doesn't seem to affect other
applications. I'd also be very curious as to what the telemetry says
about the cause of the overloads. For example, there's a world of
difference between the overload being caused by errors from the kernel
trap and overloads caused by scheduling latency or the IOProc taking
too long.
All that said, there may be a more simple cause. One thing that caught
my eye was your description of how the system was sleeping and waking
in fits and starts. I've seen that happen in processes that have
blocked on the HAL's notification thread. One thing that changed in
SnowLeopard is that by default, the HAL will use the process's main
thread for it's notifications.
It is possible that the main thread in one of your processes has
blocked and is preventing the HAL from getting notifications. If this
is the problem, the fix is pretty simple. Just be sure to set the
system object property, kAudioHardwarePropertyRunLoop, to NULL. This
will cause the HAL to run it's own thread for handling notifications,
which was the default prior to SnowLeopard.
On Oct 13, 2009, at 2:54 AM, Stéphane Letz wrote:
Message: 1
Date: Sun, 11 Oct 2009 12:15:25 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Recommended way to handle suspend/resume on notebooks
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=iso-8859-1; format=flowed;
delsp=yes
The HAL doesn't do anything special to handle sleep/wake. It just
happens. The HAL treats it just like any other large discrepancy in
time. Generally, the HAL notices it when it does the first overload
check after waking up. Ultimately, it depends on what was going on
when sleep happened as to when the HAL will first notice the
discontinuity. The result is that the HAL re-synchs the IO thread's
time line with the hardware's time stamps.
For a piece of hardware, sleep generally means that things like DMAs
are turned off and what not. So while the HAL is sorting out it's own
issues, the driver is also contending with restarting itself. In
practical terms, this usually means that the driver's time stamps
will
either re-start back at 0 or have some other large discontinuity in
both the sample and host time.
At any rate, I would expect that the result of all this re-synching
might result in a few overloads in a row (two or three seem likely
for
a lot of cases where the interruption might happen). But I would not
expect that there would be an endless stream of them followed by the
hardware stopping.
A couple of questions come to mind:
- What hardware/OS are you using?
MacPro 10.6.1 4 cores Built-in devices, Mac Book Pro 2.6 Ghz 10.6.1
Built-in devices,
- Is this behavior particular to your app or do other apps have
similar behaviors?
Does not seems to happens with a few GUI based applications i
tested... but
1) the problem does not happen on Leopard 10.5.8 (tested on the same
MacPro 4 cores)
2) Symptoms on SL the are :
- Mac Pro : I start my audio stuff (JACK server + a simple sound
generating application), suspend takes a long time to take effect
then sound stops (OK...), but resume show this continuous stream of
kAudioDeviceProcessorOverload message and sound never recover.
- Mac Book Pro: I start my audio stuff (JACK server + a simple
sound generating application), suspend goes fast, but sound still
works during several second (hum...), when resume i see strange
behaviours (like the screen switch on again, then become dark again
then switch on again, then this continuous stream of
kAudioDeviceProcessorOverload messages and sound never recover.
- Have you looked at the telemetry in HALLab?
Seems like a bug in SL, should a issue a bug 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