[1.4] startiPhoneAudioStream, when used after a movie ends, crashes the engine. -NOT RESOLVED

I've discovered that in the v1.4 build of iTorque2D, attempting to play an audio file using startiPhoneAudioStream, will cause an engine crash.

Here are the facts...

1.) Call a movie file to play

playiPhoneMovie("game/data/video/video", 0, 0);

2.) Wait for it to end. Go do stuff. Take some time, doesn't matter how long or how short. Now try to play some music.

startiPhoneAudioStream("~/data/audio/music.mp3",true);

-- CRASH --

You will see the following log in your console:

Error opening file: -43
Error opening file: -43
Error getting file format: -38
Error getting file data size: -38
Error getting file data info: -38
Error creating queue: 1718449215
Error adding isRunning property listener to queue: -50
Error setting up queue: -50

Tracing through the code, we go into SoundEngine.mm, to line 740, with the following code:

OSStatus SetupBuffers(BG_FileInfo *inFileInfo)
		{
			int numBuffersToQueue = kNumberBuffers;
			UInt32 maxPacketSize;
			UInt32 size = sizeof(maxPacketSize);
			// we need to calculate how many packets we read at a time, and how big a buffer we need
			// we base this on the size of the packets in the file and an approximate duration for each buffer
			
			// first check to see what the max size of a packet is - if it is bigger
			// than our allocation default size, that needs to become larger
			OSStatus result = AudioFileGetProperty(inFileInfo->mAFID, kAudioFilePropertyPacketSizeUpperBound, &size, &maxPacketSize);
			AssertNoError("Error getting packet upper bound size", end);
			bool isFormatVBR = (inFileInfo->mFileFormat.mBytesPerPacket == 0 || inFileInfo->mFileFormat.mFramesPerPacket == 0);
			
			CalculateBytesForTime(inFileInfo->mFileFormat, maxPacketSize, 0.5/*seconds*/, &mBufferByteSize, &mNumPacketsToRead);
			
			// if the file is smaller than the capacity of all the buffer queues, always load it at once
			if ((mBufferByteSize * numBuffersToQueue) > inFileInfo->mFileDataSize)
				inFileInfo->mLoadAtOnce = true;
			
			if (inFileInfo->mLoadAtOnce)
			{
				UInt64 theFileNumPackets;
				size = sizeof(UInt64);
				result = AudioFileGetProperty(inFileInfo->mAFID, kAudioFilePropertyAudioDataPacketCount, &size, &theFileNumPackets);
				AssertNoError("Error getting packet count for file", end);
				
				mNumPacketsToRead = (UInt32)theFileNumPackets;
				mBufferByteSize = inFileInfo->mFileDataSize;
				numBuffersToQueue = 1;
			}	
			else
			{
				mNumPacketsToRead = mBufferByteSize / maxPacketSize;
			}
			
			if (isFormatVBR)
				mPacketDescs = new AudioStreamPacketDescription [mNumPacketsToRead];
			else
				mPacketDescs = NULL; // we don't provide packet descriptions for constant bit rate formats (like linear PCM)	
			
			// allocate the queue's buffers
			for (int i = 0; i < numBuffersToQueue; ++i) 
			{
				result = AudioQueueAllocateBuffer(mQueue, mBufferByteSize, &mBuffers[i]);
				AssertNoError("Error allocating buffer for queue", end);
				QueueCallback (this, mQueue, mBuffers[i]);
				if (inFileInfo->mLoadAtOnce)
					inFileInfo->mFileDataInQueue = true;
			}
			
		end:
			return result;
		}

Within that code, the offending line is this:

OSStatus result = AudioFileGetProperty(inFileInfo->mAFID, kAudioFilePropertyPacketSizeUpperBound, &size, &maxPacketSize);

The 'result' returned by that is -38. If you do not play a movie beforehand, this will return as 0. -38 translates to "kAudioFileNotOpenError". AudioFileGetProperty is part of the iPhone APIs, so for whatever reason we can't step into it using XCode to see exactly what is going on.

But what we know is this...
- Playing music without playing a movie works fine.
- Playing music after playing a movie causes the APIs to refuse to load the file, however silently fails to load the file, informs the system that it isn't open, which will later on cause a crash.

The EXACT crash is actually caused by the fact that maxPacketSize is returned as 0. At a later point in the code, maxPacketSize is divded by another number. Since maxPacketSize is 0, the universe implodes. Loading a music file without playing a movie will properly load the audio file, properly setting maxPacketSize to a valid number, and hence preventing the destruction of the universe through a gaping black-hole.

And that's where I am on this one so far. A pretty nasty bug, and I'm kinda stuck on it.