• 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
Guardmalloc breaks after AudioQueueDispose
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guardmalloc breaks after AudioQueueDispose


  • Subject: Guardmalloc breaks after AudioQueueDispose
  • From: Greg Wilson <email@hidden>
  • Date: Mon, 08 Dec 2008 12:06:08 -0500

I've been trying to convert the simple sound play routines in my app to use the AudioQueue routines. I play either very short sounds or loop some longer ones (and both types can be playing at once). Following the aqplay/AudioQueueTest example, I got my sounds to play but eventually my program crashes, sometimes after playing 20+ sounds successfully.

After much headbanging I went back to the example code (aqplay from Developer/Examples/Core Audio/SimpleSDK/AudioQueueTools)) and altered it to play the same sound a number of times. Basically, when GuardMalloc is enabled, the program gets a EXC_BAD_ACCESS in a different thread than my program loop in a routine OSAtomicOr32Barrier called by AQConverterManager when attempting to play the sound the second time.

If GuardMalloc is not enabled, things can go to go normally for a while, sometimes even playing 20+ sounds successfully. However, it will usually crashes after playing the sound a number of times. Occasionally I get a note to set a breakpoint in malloc_error_break. When set, the debugger breaks during a calls to either AudioQueueDispose or to AduioQueueStart.


(here's what I did to alter the aqplay program. It doesn't require much to alter the program to play sounds one after the other. Basically, I created a routine (playFile )and moved the AudioQueue functions which played the file into this routine from the main routine


void playFile (const char *fpath, Float32 volume )

{
	//copy everything from here
	printf ("Playing file: %s\n", fpath);

	try {
		AQTestInfo myInfo;

... etc
	// down to here
	catch (CAXException e) {
		char buf[256];
		fprintf(stderr, "Error: %s (%s)\n", e.mOperation, e.FormatError(buf));
	}

}

then this code was replaced in the main routine to call it repeatedly:

int main (int argc, const char * argv[])
{
	const char *fpath = NULL;
	Float32 volume = 1;

	for (int i = 1; i < argc; ++i) {
		const char *arg = argv[i];
		if (arg[0] != '-') {
			if (fpath != NULL) {
				fprintf(stderr, "may only specify one file to play\n");
				usage();
			}
			fpath = arg;
		} else {
			arg += 1;
			if (arg[0] == 'v' || !strcmp(arg, "-volume")) {
				if (++i == argc)
					MissingArgument();
				arg = argv[i];
				sscanf(arg, "%f", &volume);
			} else if (arg[0] == 'h' || !strcmp(arg, "-help")) {
				usage();
			} else {
				fprintf(stderr, "unknown argument: %s\n\n", arg - 1);
				usage();
			}
		}
	}

	if (fpath == NULL)
		usage();

// these few lines replace the code moved to playfile, and play the same sound file over and over
for (int j = 1; j< 200; ++j)
playFile(fpath, volume);


return 0;
}


I put Submarine.aiff from System/Library/Sounds into the build directory and added Submarine.aiff as an argument to the active executable.

I later changed the lines
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 1, false);
XThrowIfError(AudioQueueDispose(myInfo.mQueue, true), "AudioQueueDispose(true) failed");
XThrowIfError(AudioFileClose(myInfo.mAudioFile), "AudioQueueDispose(false) failed");
delete [] myInfo.mPacketDescs;


to
do {
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 5, false);
} while (gIsRunning);

XThrowIfError(AudioQueueDispose(myInfo.mQueue, true), "AudioQueueDispose(true) failed");
XThrowIfError(AudioFileClose(myInfo.mAudioFile), "AudioQueueDispose(false) failed");
delete [] myInfo.mPacketDescs;
gIsRunning = 1;


and set the gIsRunningFlag to 1 when it was defined, ie
static UInt32 gIsRunning = 1;

(The program sets this to 0 when the queue calls it's listener proc, although it didn't use it )

This serves to ensure AudioStopQueue has really stopped the queue and it even gives it an extra bit of time to finish anything it might be doing. However, that didn't change anything. With GuardMalloc enabled, the program still broke during the second attempt at playing the sound (and after about 12 successful plays with GuardMalloc off)

Can anyone help me? I've replicated this on a PPC G5, an original intel iMac and a intel macbook all running 10.5.5 using xcode 3.1.1.


_______________________________________________ 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
  • Prev by Date: Re: Timing mechanism for MIDI ?
  • Next by Date: Re: low-pass filter on the iphone
  • Previous by thread: Re: Timing mechanism for MIDI ?
  • Next by thread: Crash in an audio driver - can someone help point me in the right direction?
  • Index(es):
    • Date
    • Thread