• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: clipIfNecessary() errors with NSSound
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clipIfNecessary() errors with NSSound


  • Subject: Re: clipIfNecessary() errors with NSSound
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 12 May 2008 11:51:01 -0700

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: This email sent to email@hidden
  • Follow-Ups:
    • Re: clipIfNecessary() errors with NSSound
      • From: Jonathan Hendry <email@hidden>
References: 
 >clipIfNecessary() errors with NSSound (From: Jonathan Hendry <email@hidden>)

  • Prev by Date: sample rate conversion on input
  • Next by Date: Re: REPOST: AudioUnitSetParameter vs AUParameterSet
  • Previous by thread: clipIfNecessary() errors with NSSound
  • Next by thread: Re: clipIfNecessary() errors with NSSound
  • Index(es):
    • Date
    • Thread