Блог

Я пытался найти реализацию потоков в IOS, которая соответствует потребностям моих проектов. До сих пор мне не удалось найти приемлемое решение.

Моя проблема :

Мне нужно одновременно считывать аудио из 16 файлов mp3 на диске.

Что я пробовал:

Во-первых, я попытался использовать NSTimer, который повторяется. Таймер работал недостаточно быстро, и звук пропадал, когда я воспроизводил более 4 файлов.

Во-вторых, я попытался использовать NSThread с приоритетом 1. Звук почти воспроизводился правильно, но пользовательский интерфейс перестал отвечать на запросы.

Наконец, я попытался отправлять блоки с помощью GCD в моем обратном вызове всякий раз, когда мне нужно было больше звука из файла. Снова звук пропадал, но пользовательский интерфейс был отзывчивым.

Во всех трех приведенных выше примерах я также пытался разделить рабочую нагрузку, создав 4 потока и заставив каждый поток обрабатывать по 4 аудиофайла, но это вызвало действительно серьезные проблемы с синхронизацией звука.

Существуют ли другие варианты потоков, которые я могу попробовать, или сделать вышеприведенный итог того, что может предложить IOS?

Считаете ли вы, что одновременное чтение 16 файлов с диска является слишком большой нагрузкой для системы IOS?

Существует ли ограничение на количество потоков, которые может обрабатывать IOS?

Чтобы мой вопрос не звучал как обсуждение, я резюмирую следующим образом.

Какая технология потоков IOS лучше всего подходит для очень частых вызовов, быстрого завершения выполнения, которая может быть легко синхронизирована и не повлияет на отзывчивость пользовательского интерфейса.

Также приветствуется любой случайный совет по решению аналогичной проблемы с программированием звука.

РЕДАКТИРОВАТЬ 1

Это несколько сокращенный код, который я смоделировал по предложению пользователя so. Все, что мне нужно, — это твердый совет о том, какая настройка будет работать лучше всего для меня. Со времени моего последнего поста я попробовал NSThread, и, похоже, у меня пропадает звук. Также я попытался использовать NSConditions, чтобы мой поток тратил вычислительную мощность, когда он не заполняет буфер, но использование этих блокировок кажется очень плохой идеей для обратных вызовов аудио.

 OSStatus channelMixerCallback(void *inRefCon, 
                              AudioUnitRenderActionFlags *ioActionFlags, 
                              const AudioTimeStamp *inTimeStamp, 
                              UInt32 inBusNumber, 
                              UInt32 inNumberFrames, 
                              AudioBufferList *ioData) { 


    AudioInfo = myaudio[inBusNumber];

    if(myaudio.needsbufferfill==YES)

    {
        [refToSelf performSelector:@selector(GetAudioForItem:) onThread:engineDescribtion.producerthread withObject:myaudio waitUntilDone:false];

    }





}

-(void) startthread

{
    engineDescribtion.producerthread =[[NSThread alloc]initWithTarget:self selector:@selector(dosinglerunloop) object:nil];

    [engineDescribtion.producerthread start];



}

-(void)dosinglerunloop
{
    BOOL isstarted=YES;
    NSAutoreleasePool *pool=[[NSAutoreleasePool alloc]init];

    do {
        [[NSRunLoop currentRunLoop]addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop]runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

    } while (isstarted);


    [pool release];

}


- (void)GetAudioForItem:(AudioInfo *)info
{

    // use data in Audio Info to seek to
    //corrent place in file
    //and extract audio to buffers

}
  

Проблема 0:

Ваши обратные вызовы аудио-рендеринга никогда не должны блокироваться. Пример: создание одного выделения кучи приведет к блокировке.

Все ваши потоки будут конкурировать за аппаратное обеспечение. Чтобы пользовательский интерфейс оставался отзывчивым, у вас не должно быть много потоков с наивысшим приоритетом (воспроизведение звука должно быть единственным). Учитывайте количество ядер, дисков и т. Д., Доступных в вашем проекте.

Если у вас все еще есть проблемы после того, как вы правильно исправили это: загрузка коротких файлов в память может разгрузить часть потребности диска в памяти.

Вы должны профилировать, чтобы определить, в чем на самом деле проблема: это может быть процессор или ввод-вывод. Возможно, вы просто пропускаете сроки рендеринга и приравниваете выпадающие аудио к «не могу читать достаточно быстро». Если вы используете много процессора, то дисковый ввод-вывод может быть не проблемой. Для декодирования и выполнения преобразования частоты дискретизации 16 файлов mp3 может потребоваться относительно высокий процессор (как один из примеров того, что вам нужно искать).

pthreads будет самым быстрым, но потребует некоторой работы для правильной реализации. На данный момент это действительно не имеет значения, потому что, похоже, пока есть несколько проблем высокого уровня, и существует несколько API, которые должны отлично справляться с этой задачей.

Ваша программа должна быть достаточно умной, чтобы определять, когда буферы чтения не могут быть заполнены достаточно быстро.

Вы предварительно заполняете буферы, правильно?

Предположительно, вы используете цикл выполнения?

Ну, есть только один диск… Таким образом, любое решение, требующее одновременного чтения 16, может быть проблемой. (В зависимости от того, привязан ли вы к вводу-выводу или к процессору.)

NSTimer не даст вам согласованных результатов.

Я не вижу никаких причин, по которым NSThread снизил бы отзывчивость пользовательского интерфейса, возможно, у вас была ошибка.

Я использую привязку этой системы к диску, потому что 16 каналов MP3 не являются проблемой для процессора на современных машинах — сколько шума исходит из вашего ящика? У меня, вероятно, возникнет соблазн использовать только один поток для заполнения пустых буферов буфером размером, соответствующим размеру (averageDiskLatency * (байт / мс) * 16 * bodgeFactor) байт аудиопотока, (bodgeFactor означает округление до границы 8 КБ и добавление нескольких 8 КБ). Всякий раз, когда потоки / обратные вызовы / что угодно очищают буфер и, следовательно, запускаются с другого, они должны помещать пустой буфер в поток чтения с диска (потокобезопасная очередь производитель-потребитель), чтобы он снова заполнился. Вероятно, каждый буфер должен включать экземпляр ‘fileControl’, содержащий спецификацию файла, дескриптор файла, переменную состояния для EOF и т. Д., Пространство строк ошибок и все остальное, необходимое для работы потока чтения, а также само буферное пространство.

Такая конструкция позволяет диску считывать хорошие, большие куски, не будучи раздражающе вытесненным на полпути при чтении и не будучи вынужденным слишком часто перемещать куски металла.

Rgds, Мартин

PS — Если у вас его еще нет, приобретите SSD-накопитель — творит чудеса с задержкой многоканального аудио / видео.