• 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: More Glitches
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More Glitches


  • Subject: Re: More Glitches
  • From: Ethan Funk <email@hidden>
  • Date: Mon, 14 Feb 2005 17:42:53 -0700

The oMutex is my output device list mutex, just making sure my output distributer list is not being manipulated before I get a device name from it. It does not involve the IO proc at all, just to get the device name when it prints a message to me so I know what HAL instance the message is about.

My IO proc reads the exact number of samples requested from the "big buffer." Glitches are not periodic, only occasional (one or twice a minute) and very short and annoying! If it was a blocking problem (a mutex or buffer being paged out, etc) in the IO proc would it not trigger an overload notification since the render did not return in time for the HAL to pass along to the output device?

This happens on three different machines ranging from a 978 MHz 12" PBG4 running 10.3.x to a old 300 MHz G3 tower running 10.2.x and a 400 MHz G4 tower running 10.3.x, all with the built-in sound device. DIGI001 also does the same (when it works... DIGI001 coreaudio driver sucks!)

Ethan...

On Feb 14, 2005, at 17:25, William Stewart wrote:

Where does oMutex come from? Is that involved in the I/O thread at all?

Are you sure that the data you are providing to the output unit is contiguous - you must supply exactly what the output unit asks for - no more/no less = you can't adjust the output unit's buffers. That is, the output unit say will ask you for stereo, 512 frames of data - you have to give it stereo, 512 frames of data....

Bill

On 14/02/2005, at 2:35 PM, Jeff Moore wrote:

The HAL only sends overload notifications when it detects them as part of the normal execution of the house keeping code at the end of each IO cycle. The HAL doesn't have any magical insight, so if you are getting glitches without a corresponding overload, it would imply that the glitching isn't related to the time being spent on the IO thread.

On Feb 14, 2005, at 12:58 PM, Ethan Funk wrote:

In my eternal hunt for the source of audio glitching, I have added the following code to my project to I can get a message on each HAL output processor overload event. However, I'm not getting any messages, even through I hear glitches. Am I doing something wrong in setting up notification or is it possible that the glitches are due to something else?

Here is my code for the callback: msg is a Boolean I set to true for debugging

OSStatus HALOverloadListener(AudioDeviceID inDevice, UInt32 inChannel, Boolean isInput, AudioDevicePropertyID inPropertyID, void *inRefCon)
{
Distributor *output = (Distributor *)inRefCon;

if(msg){
output_map_ptr dp;
string dataStr = "unknown";
// find the output in the output distributer list
pthread_mutex_lock( &oMutex );
for (dp=outputMap.begin(); dp!=outputMap.end(); dp++){
if(&((*dp).second) == output)
dataStr = (*dp).first;
}
pthread_mutex_unlock( &oMutex );
// print message
fprintf(stdout, " MESSAGE: Processor Overload on %s output, bus #%ld.\n", dataStr.c_str(), inChannel);
fprintf(stdout, "ae>");
fflush(stdout);
}
return noErr;
}


Then I register the call back just before AU Initialization deep in my audio setup procedure:

// set up notification of processor overload
err = AudioDeviceAddPropertyListener(devID, 0, FALSE, kAudioDeviceProcessorOverload, HALOverloadListener, this);
if (err)
return false;

// initialize the HALoutput AU
err = AudioUnitInitialize(outHALUnit);
if (err)
return false;

There is NO error when I add the property listener. Any insight would be appreciated!
Ethan...

-- 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

-- mailto:email@hidden
tel: +1 408 974 4056

_______________________________________________________________________ ___
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
_______________________________________________________________________ ___

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden

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
References: 
 >More Glitches (From: Ethan Funk <email@hidden>)
 >Re: More Glitches (From: Jeff Moore <email@hidden>)
 >Re: More Glitches (From: William Stewart <email@hidden>)

  • Prev by Date: Re: More Glitches
  • Next by Date: Re: More Glitches
  • Previous by thread: Re: More Glitches
  • Next by thread: envelope error
  • Index(es):
    • Date
    • Thread