Problemas de performance con AVAssetWriterInput (audio) y dispositivos de un solo núcleo

Tengo un extraño problema de performance con AVAssetWriterInput en AVAssetWriterInput de un solo núcleo como el iPhone 3GS y el iPhone 4. Básicamente, tengo un AVAssetWriter con dos AVAssetWriterInputs, uno para video y otro para audio. Aproximadamente, parece:

 AVAssetWriter * assetWriter = [[AVAssetWriter alloc] initWithURL:videoURL fileType:AVFileTypeMPEG4 error:&error]; videoWriterInput = [AVAssetWriterInput assetWriterInputWithMediaType:AVMediaTypeVideo outputSettings:videoSettings]; videoWriterInput.expectsMediaDataInRealTime = YES; NSDictionary * audioSettings = [NSDictionary dictionaryWithObjectsAndKeys: [NSNumber numberWithInt:kAudioFormatMPEG4AAC], AVFormatIDKey, [NSNumber numberWithInt:64000], AVEncoderBitRateKey, [NSNumber numberWithInt:2], AVNumberOfChannelsKey, [NSNumber numberWithInt:44100], AVSampleRateKey, currentChannelLayoutData, AVChannelLayoutKey, nil]; audioWriterInput = [AVAssetWriterInput assetWriterInputWithMediaType:AVMediaTypeAudio outputSettings:audioSettings]; audioWriterInput.expectsMediaDataInRealTime = YES; [assetWriter addInput:videoWriterInput]; [assetWriter addInput:audioWriterInput]; 

También hay un AVAssetWriterInputPixelBufferAdaptor allí, pero lo dejé por brevedad. Creo una queue de envío en serie que utilizo para la grabación de audio y video. Cuando obtengo un nuevo marco de video, envío el trabajo a esa queue de serie, y cuando obtengo nuevos bytes de audio, envío ese trabajo a la misma queue de serie. De esta forma, la mayor parte del código de escritura de audio no ocurre en el hilo de callback de audio (que de lo contrario ralentizaría el hilo de audio de alta prioridad).

Soy capaz de escribir un video con audio con éxito y funciona bien en dispositivos de doble núcleo. Sin embargo, en los dispositivos de un solo núcleo, me parece que hay un tartamudeo notable en la pantalla del dispositivo aproximadamente cada 500-700ms. He rastreado al culpable de lo siguiente:

 if ([audioWriterInput isReadyForMoreMediaData]) { if (![audioWriterInput appendSampleBuffer:sampleBuffer]) { NSLog(@"Couldn't append audio sample buffer: %d", numAudioCallbacks_); } } 

Si comento el appendSampleBuffer para el audioWriterInput , obviamente no se escribe ningún audio, pero tampoco hay tartamudeo en la pantalla real. Es extraño porque todo esto sucede fuera del hilo principal. Los times de la CPU / GPU por cuadro son del order de 4-5 ms, por lo que no es como si la CPU / GPU tuviera un cuello de botella.

Otra pista / curiosidad: cuando escribo buffers de audio, obtengo un gráfico de memory con dientes de sierra como el siguiente:

diente de sierra

Me parece que audioWriterInput está haciendo queue en algunos búferes y luego escribiendo / liberándolos.

Una última pista es que parece que el tartamudeo es less severo cuando grabo como mono en lugar de estéreo. Desafortunadamente, los sonidos que entran son estéreo, así que cuando hago eso, el sonido está mal. De cualquier manera, la tartamudez no desaparece por completo, por lo que no es realmente una solución válida, pero podría insinuar el hecho de que estéreo requiere más resources para manejar.

¿Alguien tiene ideas sobre por qué escribir audio con el AVAssetInputWriter provoca que la aplicación entera tartamude? Estos dispositivos obviamente solo tienen un núcleo para que todos los subprocesss se ejecuten, pero parece extraño que el subprocess principal deba tartamudear cuando la carga de la CPU es tan baja.