Re: clipIfNecessary() errors with NSSound
Re: clipIfNecessary() errors with NSSound
- Subject: Re: clipIfNecessary() errors with NSSound
- From: Jonathan Hendry <email@hidden>
- Date: Mon, 12 May 2008 19:34:19 -0400
Okay, I was able to collect some data and eventually caught some
glitches, but I'm not sure what to do with the information, since our
audio code consists only of using [[NSSound soundNamed:soundName] play].
Since the HALLab output isn't synchronized with any other trace
information, it's hard to correlate the errors with other things
happening in the application.
I think we're going to roll back to Tiger.
Thanks for your help though!
- Jon
On May 12, 2008, at 2:51 PM, Jeff Moore wrote:
Sigh. That log message is a red herring I'm afraid. Generally, this
message is not indicative of any actual error that took place while
your app was running. It simply means that two processes are
playing at the same time. It is generated when the second process
starts the hardware.
At any rate to get to the bottom of why your app is glitching, I'd
start by examining the IO cycle telemetry that you can get from
your app using HALLab. It is actually pretty easy to use. You bring
up a telemetry window, use the UI to indicate the process ID and
the device whose telemetry you wish to monitor. Then you set the
capture rate to something other than off (1 second works well) and
then start playing audio with the target application. As the target
application's IO thread does it's thing, the information about it
will fill in the table. When you are done, just turn the capture
rate back to off.
Note that on Leopard, IO cycle telemetry is disabled by default. To
enable it, you need to execute "sudo touch /var/
db/.com.apple.audio.telemetryenabled" on a command line.
The data in the table can be presented in two ways. First, there is
raw mode. It dumps every telemetry event onto a line. Then there is
cycle mode. This collates the events into IO cycles and presents
each cycle's crucial info on a single line. A disclosure triangle
is available to reveal the raw events for each cycle. The
"Previous" and "Next" buttons move the selection to the previous/
next cycle that has an error in it.
The actual meaning of each event can be traced back through the
code. But basically, each event marks the beginning ("->") or end
("<-") of some phase of the IO cycle. The events give you a good
handle on where the time in the cycle is spent. The error events
can also indicate what the specific problem might have been.
On May 11, 2008, at 5:15 AM, Jonathan Hendry wrote:
We have a Cocoa app that runs neuroscience experiments. Audio
stimuli are played using NSSound. The sounds are a few aiff files
of 50k-200k. The stimuli are played frequently, and the
application needs to run pretty much all day. In addition to the
audio stimuli, there are visual stimuli presented via OpenGL on a
captured second screen, and the main screen shows a variety of
status windows and graphs. And it's pulling a few channels of data
from an Analog-Digital Converter box.
After upgrading a dual-2.5 GHz G5 to Leopard, we're seeing
dropouts like the following on it:
May 9 17:01:12 dhc017024 kernel[0]: IOAudioStream
[0x34be600]::clipIfNecessary() - Error: attempting to clip to a
position more than one buffer ahead of last clip position
(124,3029)->(126,2651).
May 9 17:01:12 dhc017024 kernel[0]: IOAudioStream
[0x34be600]::clipIfNecessary() - adjusting clipped position to
(125,3029)
This happens with either the internal audio, or when using a USB
audio card (without a specific driver, so it might be using the
same driver as the internal.)
iTunes plays without error on the same machine, even when under
heavy load (visualizer). Normally, the experiment app uses 15%-25%
CPU.
Adjusting volume or muting/unmuting through the keyboard seems to
be something that can trigger the problem, but I'm not certain.
Is there a workaround for this? Would there be any benefit to
dropping down to CoreAudio or the SystemSound API? I'd rather not
dig into CoreAudio and find that it doesn't fix the problem.
I noticed the ADC Q&A QA1467, "Apple also provides the HALLab
utility (/Developer/Examples/CoreAudio/HAL/HALLab). You can use
this application to monitor the statistics of your I/O cycle to
get a better idea of where in the cycle the overload is occurring.
This information can found in the IO Telemetry window (File-
>New:)." Unfortunately I can't make head nor tail of how to use
that window. How does one get data into the table view? Clicking
'Next' or 'Previous' causes a crash, I think because there are no
entries in the table.
Any advice would be appreciated. Any DTrace tricks?
--
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:
40hms.harvard.edu
This email sent to email@hidden
_______________________________________________
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