iPad барабанный компьютер touch-›задержка звука

Мы создали драм-компьютерное приложение для iPad, чтобы играть под живую музыку (на сцене или в вашей спальне). Настройка довольно проста: вы нажимаете одну из кнопок, и соответствующий семпл воспроизводится. Все работает довольно гладко, но, к сожалению, есть небольшая (хотя и раздражающая) задержка между моментом, когда вы опускаете палец, и воспроизведением звука. Я пытался измерить величину задержки (на слух), она составляет примерно 0,05–0,1 секунды.

Воспроизведение звука было реализовано с использованием фреймворка AudioToolbox (Extended Audio File Services, Audio Units). Звуки передаются из файла, который хранится на устройстве, чтобы сократить время загрузки между разными банками звуков. Сэмплы представлены в необработанном формате wav (линейный PCM, 16-битное целое число со знаком с прямым порядком байтов, 2 канала, 44100 Гц), что, насколько я понимаю, должно быть самым быстрым для обработки (в отличие от чего-то сжатого, например mp3).

Я измерил время между нажатием кнопки (событие касания UIButton) и доставкой первых кадров семпла в микшер (посредством обратного вызова воспроизведения). Он достаточно стабилен и составляет от 0,02 до 0,03 секунды. Мне это кажется довольно быстрым, но может быть недостаточно быстрым.

Может ли это быть проблемой или может быть что-то еще, например, задержка доставки сенсорных событий?

ОБНОВЛЕНИЕ:

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

Хотя это уменьшает задержку, нажатие кнопки -> воспроизведение по-прежнему составляет от 0,005 до 0,02 секунды (но чаще 0,02). Это до сих пор заметно. Я думаю, это может быть связано с размером буфера обратного вызова воспроизведения, который в настоящее время составляет 1024 байта.

Любые идеи о том, как это сделать? Установка kAudioUnitProperty_MaximumFramesPerSlice не работает.


person Jeroen Bouma    schedule 28.12.2011    source источник
comment
Я предполагаю, что проблема с потоковыми файлами. Вы никогда не должны недооценивать скорость (или ее отсутствие) при использовании файловой системы текущего мобильного устройства. Попробуйте предварительно загрузить и играть прямо из памяти.   -  person Till    schedule 28.12.2011


Ответы (2)


Я решил проблему задержки, указав предпочтительную продолжительность аппаратного буфера ввода-вывода, как указано в Пособие по аудиосеансам

NSTimeInterval preferredBufferDuration = 0.005;
[audioSession setPreferredIOBufferDuration:preferredBufferDuration error:&audioSessionError];

if (audioSessionError != nil) 
{
    NSLog (@"Error setting preferred buffer duration.");
    return;
}

Установив длительность буфера на 0,005, вашему приложению нужно будет предоставлять только 256 байт (на частоте 44 кГц) в каждом цикле. Это (очевидно) уменьшает задержку с 0,02 до 0,005, но звук должен воспроизводиться с большей скоростью.

iPad 2 прекрасно справляется с такой скоростью, даже когда IO читается с диска. К сожалению, iPad первого поколения недостаточно быстр (с дисковым вводом-выводом и без него), поэтому я надеюсь, что смогу найти способ различить их и дать iPad 1 немного больше задержки для лучшей производительности.

person Jeroen Bouma    schedule 29.12.2011

Вы можете использовать инструменты с TimeProfiler (Apple Documentation on Instruments), чтобы узнать, какие именно методы требуют много времени для запуска. При запуске обязательно снимите флажок «Инвертировать дерево вызовов» и установите флажок «Скрыть системные библиотеки».

person cvursache    schedule 28.12.2011
comment
Я не знал, что в Instruments встроена эта функция. Это определенно поможет мне определить проблему, спасибо! - person Jeroen Bouma; 29.12.2011