2016-02-17 7 views
0

Я устанавливаю предпочтительную продолжительность буфера 0.0001 секунд, используя AVAudioSession и не получая логических результатов с помощью тренажеров.AVAudioSession Buffer Продолжительность на iphone6 ​​* Симулятор

[session setPreferredIOBufferDuration:self.bufferDuration error:&audioSessionError]; 
    if (audioSessionError) { 
     NSLog(@"Error %ld, %@", 
      (long)audioSessionError.code, audioSessionError.localizedDescription); 
    } 

Проблема заключается в том, что в моих Audio Unit делают обратные вызовы, я всегда получаю 512 кадры обрабатывать как inNumberFrames аргумента.

На моем устройстве установка предпочтительной продолжительности буфера приводит к разным скоростям буфера. Например, если я установил self.bufferDuration, а затем установил AVAudioSession с 0.1, то я получу 4096 аргументы inNumberFrames для моих обратных вызовов рендеринга. На симуляторе это будет 512.

Я хотел проверить, нормально ли это поведение (я знаю, что многие вещи не работают одинаково на симуляторе и устройстве), или если это проблема с моими предположениями.

ответ

1

Обратите внимание, что параметр setPreferredIOBufferDuration является предпочтительным предложением, а не жесткой настройкой. ОС свободно во время выполнения, чтобы выбрать несколько кадров (длительность фактических данных, умноженных на частоту дискретизации) для отправки на обратные вызовы звука, и даже изменить этот номер, пока приложение работает на переднем плане. Фактическая продолжительность может различаться между различными устройствами iOS и системами Mac. Продолжительность может также зависеть от частоты дискретизации или формата, аудиомаршрута, есть ли какие-либо другие активные сеансы аудиофайлов в фоновом режиме, настройки звука, используемые непосредственно предыдущим приложением, и/или версии OSX или iOS и версии симулятора iOS.

Для запрашиваемой продолжительности буфера 0,0053, мне кажется, чтобы получить 512 кадров на IOS 9.2 Simulator, и 256 кадров на iPhone 6s (только последние согласования запроса, но это будет не быть правдой вообще общего частота выборки). Некоторые более старые устройства iOS не возвращают число кадров ниже 256.

Недопустимо считать, что inNumberFrames будет соответствовать настройке продолжительности буфера приложения.

+0

Вопрос был конкретно в этом вопросе о том, как получить обратные вызовы с размером кадра 512 на симуляторе, и если это нормальное поведение. Я прочитал все руководство по программированию «AVAudioSession», и поэтому я знаю об этих разных режимах выполнения и о том, как настройка является просто запросом. (хотя этот запрос должен быть детерминированно соблюден в отсутствие указанных случаев краев, нет?). –

+0

Интересно, что использование функции 'CoreAudio'' AudioUnitGetProperty() 'с' kAudioUnitProperty_MaximumFramesPerSlice' возвращает фреймы '4096', даже если скорость буфера возвращается к фреймам' 512' во время выполнения. (Я вызываю этот приемник после запуска пульта 'remoteIO'). Проблема в том, что у меня есть визуальный код отображения, который показывает формы сигналов и масштаб которых определяется фактическими размерами кадров во время выполнения. Таким образом, на симуляторе он ожидает «4096», и действительно, это то, что возвращает AudioUnitGetProperty(), но звуковые данные имеют только «512» кадров, поэтому я вижу, что осциллограммы охватывают только экран 1/8. –

+0

Правильная техника заключается в использовании кольцевого буфера без блокировки, так что длина волны сигнала дисплея Ui и длина буфера обратного вызова звука полностью развязаны и независимы. Я использую эту технику в своих приложениях для iOS, чтобы изменить длину представления формы сигнала и длину FFT в очень широком диапазоне, не завися от продолжительности звукового буфера и не меняя его. – hotpaw2