Общие вопросы

Каков эффект составных устройств с точки зрения программирования драйвера?

Составные устройства заставляют многократные устройства вести себя как единое устройство. В процессе, Core Audio выполняет некоторую дополнительную работу для сглаживания синхронизации несоответствий.

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

Я должен создать “целое устройство” поток, содержащий все выводы от моего устройства, или просто поток для каждой пары вводов/выводов?

Это полностью ваше дело. Составные устройства делают это в основном надуманным вопросом. Однако может быть удобно обеспечить “целое устройство” поток для лучше поддержки аудиоприложений в версиях OS X до версии 10.4.

Как драйверы взаимодействуют с Установкой Аудио/MIDI?

Установка аудио/MIDI представляет стандартные средства управления для аудиоустройства, вместе с потоковыми возможностями выбора. Здесь нет никакого волшебства. Однако этот вопрос часто подходит в сочетании с проблемой пользовательских элементов управления. В этом случае некоторая дополнительная работа необходима. Этот процесс описан далее в Создании Пользовательских элементов управления.

Демонстрационные буферные проблемы

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

Размер демонстрационного буфера ограничивается многими факторами. Для одного должно быть принято во внимание демонстрационное смещение (не демонстрационная задержка). Если аудио механизм установлен считать 1 000 выборок позади аппаратных средств (например), должна быть комната больше чем для 1 000 выборок в буфере. Фактически, должно быть по крайней мере два дополнительных кадра — тот, в котором аппаратные средства пишут и кадр, стираемый перед ним.

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

Каково различие между демонстрационной задержкой и демонстрационным смещением?

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

Демонстрационное смещение является функцией, разработанной для аудиоустройств на основе блока I/O. Рассмотрите устройство вывода как пример. Если аудиоустройство передает данные в пакетной сделке с 32 выборками, это должно иметь по крайней мере 32 выборки в наличии, когда просыпается аудио механизм. Иначе, механизм не будет в состоянии стоять в очереди поблочная передача и закончит тем, что подсунул цикл, потенциально приводя к незначительному сбою. Для решения этой проблемы можно указать демонстрационное смещение, чтобы гарантировать, что более высокие уровни остаются определенное расстояние перед головой I/O.

У меня есть значительные проблемы производительности при выполнении пользовательского ввода/вывода, просачивающегося мой драйвер. Как я могу улучшить производительность?

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

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

Я не делаю никакой пользовательской фильтрации, но у меня все еще есть проблемы производительности (уволенные, заикание, и т.д.). Какие-либо идеи?

Наиболее распространенная причина аудио незначительных сбоев плохо устанавливает метку времени. Посмотрите Взятие Метки времени для подробных предложений. При использовании блочных устройств или других устройств, где метка времени не может быть взята точно, когда буфер повторяется, можно также счесть пример кода в Фальсифицировании Меток времени полезным.

Фальсифицирование меток времени

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

Следующий фрагмент кода показывает простой пример того, как работать вокруг этой проблемы:

void set_timestamp_adjusted(int current_bufpos)

{

    static int sec=0, usec=0, lastsec, lastusec=0, lastpos=0;

    int len, stampsec, stampusec;

    uint64_t curtm, lasttm, stampoff, stamptm

    clock_get_system_microtime(&sec, &usec);

    if (!lastsec && !lastusec) {

        // Engine just started. Initialize values.

        lastsec = sec;

        lastusec = sec;

    }

    curtm = (sec * 1000000UL) + usec; // usec since startup.

    lasttm = (lastsec * 1000000UL) + lastusec;

    stampoff = ((lasttm - curtm) * (uint64_t)(BUFFER_SIZE - lastpos))  /

            (uint64_t)len;

    stamptm = lasttm + stampoff;

    stampsec = (int)(stamptm / 1000000ULL);

    stampusec = (int)(stamptm % 1000000ULL);

    lastpos = current_bufpos;

    // set timestamp here.

}

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

Создание пользовательских элементов управления

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

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

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

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