Аудиоустройство программируемая структура и жизненный цикл

Следующее число представляет рабочее аудиоустройство, созданное с SDK. Данные показывают аудиоустройство в контексте с его представлением и с приложением — известный как узел — который использует аудиоустройство:

Данные показывают две отличных внутренних детали пакета аудиоустройства: само аудиоустройство, слева, и представление аудиоустройства, справа. Аудиоустройство выполняет работу со звуком. Представление обеспечивает графический интерфейс пользователя для аудиоустройства, и, если Вы обеспечиваете его, поддерживаете для автоматизации параметра. (См. Автоматизацию Параметра Поддержки.), Когда Вы создаете аудиоустройство, Вы обычно пакет обе части в том же пакете — как Вы учитесь делать позже — но они - логически отдельные части кода.

Аудиоустройство, его представление и хост-приложение связываются друг с другом посредством центра уведомления, установленного хост-приложением. Это позволяет всем трем объектам оставаться синхронизируемыми. Функции для центра уведомления являются частью События Аудиоустройства Core Audio API.

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

Аудиоустройство и его представление появляются, и в игру, одним из двух способов:

• Как правило, пользователь указывает к хост-приложению, что они хотели бы использовать аудиоустройство. Например, пользователь мог попросить, чтобы узел применил эффект реверберации к каналу аудио.

• Для аудиоустройства, которое Вы предоставляете для добавления опции к собственному приложению, приложение открывает аудиоустройство непосредственно, вероятно на запуск приложения.

Когда узел открывает аудиоустройство, он сцепляет аудиоустройство до цепочки аудиоданных узла — представленный в числе светло-желтым (аудиоданные) стрелки. Это поднимает трубку, имеет две части: обеспечение новых аудиоданных к аудиоустройству и получения обработанных аудиоданных от аудиоустройства.

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

• Для получения обработанных аудиоданных от аудиоустройства узел вызывает метод рендеринга аудиоустройства.

Вот то, как аудиоданные текут доходы между хост-приложением и аудиоустройством:

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

2. Аудиоустройство отвечает путем вызова функции обратного вызова узла, чтобы заставить часть выборок аудиоданных обрабатывать

3. Аудиоустройство обрабатывает выборки аудиоданных и помещает результат в буфер вывода для узла для получения

4. Узел получает обработанные данные и с другой стороны вызывает метод рендеринга аудиоустройства

В описании аудиоустройства на рисунке 1-1 внешний куб представляет сменный API. Apple обеспечивает Спецификацию Аудиоустройства, определяющую сменный API для множества типов аудиоустройства. При разработке аудиоустройства к этой спецификации оно будет работать с любым хост-приложением, также следующим за спецификацией.

Внутри, аудиоустройство содержит программируемые леса для соединения сменного API с пользовательским кодом. При использовании Core Audio SDK для создания аудиоустройства, эти леса предоставляются в форме кода связующего звена для Менеджера компонентов вместе с иерархией класса C++. Рисунок 1-1 (скорее фигурально) представляет Ваш пользовательский код как внутренний куб в аудиоустройстве и представляет классы SDK’s и код связующего звена как распорки, подключающие внутренний куб к внешнему кубу.

Можно создать аудиоустройство, не используя Core Audio, SDK, но делая так влечет за собой гораздо больше работы. Apple рекомендует использовать Core Audio SDK для всех кроме самой специализированной разработки аудиоустройства.

Для приобретения знаний о внутренней архитектуре аудиоустройства считайте Архитектуру Аудиоустройства в Аудиоустройстве.

Файловая структура аудиоустройства

Аудиоустройство похоже на это в файловой системе OS X:

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

Как компонент, аудиоустройство имеет следующие характеристики файловой системы:

• Это - пакет с a .component расширение файла

• Это - пакет; пользователи рассматривают пакет как непрозрачный, когда они просматривают его в Средстве поиска

Информационный список свойств (Info.plist) файл на верхнем уровне пакета Contents папка предоставляет критическую информацию системе и хост-приложениям, хотящим использовать аудиоустройство. Например, этот файл обеспечивает:

• Уникальная строка идентификатора пакета в форме обратного доменного имени (или универсальный идентификатор типа). Например, для аудиоустройства FilterDemo, предоставленного в Core Audio SDK, этот идентификатор com.apple.demo.audiounit.FilterDemo.

• Имя файла, в пакете, который является надлежащим аудиоустройством. Этот файл в MacOS папка в пакете.

Пакет аудиоустройства может содержать настроенный пользовательский интерфейс, названный представлением. Стандартное расположение для представления находится в пакете аудиоустройства Resources папка. Аудиоустройство, показанное на рисунке 1-2, включает такое представление, упакованное как сам непрозрачный пакет. Взгляд в пакете представления аудиоустройства показывает, что представление связывает файловую структуру:

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

Пакет аудиоустройства обычно содержит одно аудиоустройство, как описано в этом разделе. Но единственный пакет аудиоустройства может содержать любое число аудиоустройств. Например, пакеты Apple все его аудиоустройства в одном пакете, System/Library/Components/CoreAudio.component. CoreAudio.component пакет включает единственный файл исполняемого кода, содержащего все аудиоустройства Apple и другой файл, содержащий все предоставленные пользовательские представления:

Некоторая основная терминология

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

• «Аудиоустройство» обычно относится к исполняемому коду в MacOS папка в пакете аудиоустройства, как показано на рисунке 1-2. Это - часть, выполняющая работу со звуком. Иногда, как в заголовке этого документа, «аудиоустройство» относится в контексте ко всему пакету аудиоустройства и его содержанию. В этом случае термин «аудиоустройство» соответствует представлению пользователем плагина в файловой системе OS X.

• “Представление аудиоустройства” относится к графическому интерфейсу пользователя для аудиоустройства, как описано в Представлении Аудиоустройства. Как показано на рисунке 1-2, код для пользовательского представления обычно живет в его собственном пакете в Resources папка в пакете аудиоустройства. Представления являются дополнительными, потому что AudioUnit платформа позволяет хост-приложению создать универсальное представление на основе параметра и кода свойства в аудиоустройстве.

• “Пакет аудиоустройства” относится к файловой системе, упаковывающей, который содержит аудиоустройство и, дополнительно, пользовательское представление. Когда этот документ использует “пакет аудиоустройства “, это - характеристики упаковки, такие как расширение файла и Info.plist файл, которые важны. Иногда, как в описании того, где установить аудиоустройства, “пакет аудиоустройства” относится к содержанию, а также упаковке. В этом случае это походит на разговор о папке при значении папки и ее содержания.

Природа плагинов

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

OS X обеспечивает две сменных технологии: архитектура Базовой Основы CFPlugin и Менеджер компонентов. Аудиоустройства являются основанными на менеджере компонентов плагинами. Позже в этом разделе Вы узнаете о поддержке Менеджера компонентов в Ваших аудиоустройствах.

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

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

Учебное руководство: Используя аудиоустройство в хост-приложении

Это миниучебное руководство иллюстрирует динамический характер плагинов:

• Добавление аудиоустройства к рабочему хост-приложению

• Используя аудиоустройство

• Удаление аудиоустройства от рабочего хост-приложения

По пути это учебное руководство показывает Вам, как начать с очень полезным приложением AU Lab.

1. Запустите хост-приложение аудиоустройства AU Lab (в /Developer/Applications/Audio/) и создайте новый документ AU Lab. Если Вы не сконфигурировали AU Lab для использования стиля документа по умолчанию, Создавание Нового Окна документа открывается. Если AU Lab уже работала, выберите File> New для получения этого окна.

Гарантируйте, что конфигурация соответствует настройки, показанные в числе: встроенное Аудио для Аудиоустройства, Строки В для Входного Источника и Стерео для Каналов вывода. Оставьте вкладку Inputs окна несконфигурированной; Вы укажете ввод позже. Нажать «OK».

Новое окно AU Lab открывается, показывая канал вывода, который Вы указали.

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

(Более точно Менеджер компонентов OS X вызвал инстанцирование и закрытие аудиоустройств от имени AU Lab. Требования Менеджера компонентов для Аудиоустройств, ниже, объясняет это.)

2. В AU Lab выберите Edit> Add Audio Unit Generator. Диалоговое окно открывается из окна AU Lab, чтобы позволить Вам указать модуль генератора для служения в качестве источника аудиосигналов.

В диалоговом окне гарантируйте, что модуль генератора AUAudioFilePlayer выбран в раскрывающемся Генераторе. Чтобы последовать этому примеру, измените Название группы на Проигрыватель. Нажать «OK».

Можно изменить название группы в любое время путем двойного щелчка по нему в окне AU Lab.

Окно AU Lab теперь показывает дорожку стереовхода. Кроме того, окно инспектора открылось для модуля генератора. При закрытии инспектора можно вновь открыть его путем нажимания прямоугольной кнопки «AU» около вершины дорожки Проигрывателя.

3. Добавьте один или несколько аудиофайлов к списку Аудиофайлов в инспекторе проигрывателя окно. Сделайте это путем перетаскивания аудиофайлов от Средства поиска, как показано в числе. Помещение некоторых аудиофайлов в инспекторе проигрывателя, которого окно позволяет Вам отправить аудио через приложение AU Lab, и через аудиоустройство, которое Вы добавляете к дорожке Проигрывателя. Примерно любой аудиофайл сделает. Для этого примера музыкальный файл работает хорошо.

Now AU Lab сконфигурирована и готова к Вам добавить аудиоустройство.

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

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

Выберите аудиоустройство из раскрывающегося. Чтобы последовать этому примеру, выберите аудиоустройство AUParametricEQ из подменю Apple. (Это аудиоустройство, предоставленное как часть OS X, является эквалайзером единственной полосы со средствами управления для центральной частоты, усиления и Q.),

AU Lab просит, чтобы Менеджер компонентов инстанцировал аудиоустройства, которое Вы выбрали. AU Lab тогда инициализирует аудиоустройство. AU Lab также открывает Какао аудиоустройства универсальное представление, появляющееся как служебное окно:

Вы теперь динамично добавили аудиоустройство AUParametricEQ к рабочему хост-приложению AU Lab.

5. Для демонстрации функций аудиоустройства в AU Lab щелкните по кнопке воспроизведения в инспекторе AUAudioFilePlayer для отправки аудио через аудиоустройство. Варьируйтесь ползунки по универсальному представлению для слушания работы аудиоустройства.

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

От всплывающего меню выберите Remove AUParametricEQ.

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

Роль Core Audio SDK

При создании аудиоустройства с помощью Core Audio SDK Вы получаете леса Менеджера компонентов бесплатно. Вы также получаете всестороннюю поддержку большей части Спецификации Аудиоустройства. Это позволяет Вам сконцентрироваться на более интересных аспектах разработки аудиоустройства: обработка аудиоданных и пользовательский интерфейс.

Вы создаете основанное на SDK аудиоустройство путем разделения на подклассы надлежащих классов в иерархии класса C++ аудиоустройства SDK’s. Приложение: Иерархия классов Аудиоустройства показывает эту иерархию.

Хост-приложения связываются с аудиоустройствами через их сменный API и посредством Менеджера компонентов. В целом, существует шесть организаций кода, сотрудничающих для поддержки рабочего аудиоустройства:

• Пакет аудиоустройства. Пакет обертывает аудиоустройство и его представление (если Вы обеспечиваете пользовательское представление), и обеспечивает идентификацию для аудиоустройства, позволяющего OS X, и Менеджер компонентов используют аудиоустройство.

• Само аудиоустройство. При создании аудиоустройства с Core Audio SDK, как рекомендуется, аудиоустройство наследовалось от иерархии классов SDK’s.

• Представление аудиоустройства.

• Core Audio платформы API.

• Менеджер компонентов.

• Хост-приложение.

Отошлите к Быстрому Туру по Core Audio SDK, если требуется узнать об остальной части SDK.

Требования менеджера компонентов для аудиоустройств

Менеджер компонентов выступает в качестве посредника для хост-приложения и аудиоустройств, которые он использует — открытие, открытие, инстанцирование и закрытие аудиоустройств от имени узла.

Для OS X для распознавания аудиоустройств они должны удовлетворить определенные требования. Они должны:

• Будьте упакованы как компонент, как определено Менеджером компонентов

• Имейте единственную точку входа, которую распознает Менеджер компонентов

• Имейте ресурс (.rsrc) файл, указывающий уникальный идентификатор в масштабе всей системы и строку версии

• Реагируйте на вызовы Менеджера компонентов

Удовлетворение этих требований с нуля является значительным усилием и требует сильного схватывания Менеджера компонентов API. Однако Core Audio SDK изолирует Вас от этого. Как продемонстрировано в главе Учебное руководство: Создание Простого Модуля Эффекта с Универсальным Представлением, размещая Менеджер компонентов требует очень небольшой работы при использовании SDK.

/System/Library/Components/

Идентификация аудиоустройства

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

Менеджер компонентов идентифицирует аудиоустройства триплетом четырех кодов символов:

• «Тип» указывает общий тип функциональности, предоставленной аудиоустройством. Таким образом, тип также идентифицирует сменный API аудиоустройства. Таким образом код типа является программно значительным. Например, хост-приложение знает что любое аудиоустройство типа 'aufx' (для “эффекта аудиоустройства”), обеспечивает функциональность DSP.

  Спецификация Аудиоустройства указывает доступные коды типа для аудиоустройств, а также сменный API для каждого типа аудиоустройства.

• «Подтип» описывает более точно, что аудиоустройство делает, но не является программно значительным для аудиоустройств.

  Например, OS X включает модуль эффекта подтипа 'lpas', названный, чтобы предположить, что это обеспечивает фильтрацию низких частот. Если для Вашего аудиоустройства Вы используете один из подтипов, перечисленных в AUComponent.h заголовочный файл в платформе Аудиоустройства (такой как 'lpas'), Вы намекаете пользователям Вашего аудиоустройства, что оно ведет себя как именованный подтип. Однако хост-приложения не делают предположений о Вашем аудиоустройстве на основе его подтипа. Вы свободны использовать любой код подтипа, включая подтипы, названные с только строчными буквами.

• “Код производителя” идентифицирует разработчика аудиоустройства.

  Apple ожидает, что каждый разработчик зарегистрирует код производителя, как “код создателя “, на странице Data Type Registration. Коды производителя должны содержать по крайней мере один символ верхнего регистра. После того, как зарегистрированный, можно использовать тот же код производителя для всех аудиоустройств.

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

Как компонент, аудиоустройство идентифицирует свою версию как восьмиразрядное шестнадцатеричное число в его ресурсе (.rsrc) файл. Поскольку Вы будете видеть в Учебном руководстве: Создавая Простой Модуль Эффекта с Универсальным Представлением, Вы указываете эту информацию с помощью XCode.

Вот пример того, как создать номер версии. Это использует искусственно большое количество для иллюстрирования формата однозначно. Для десятичного номера версии 29.33.40, шестнадцатеричный эквивалент 0x001d2128. Формат работает следующим образом на это число:

Четыре старших значащих шестнадцатеричных цифры представляют номер основной версии. Следующие два представляют номер вспомогательной версии. Две младших значащих цифры представляют точечный номер выпуска.

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

Сменные требования API для аудиоустройств

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

Реализация сменного API для любого данного типа аудиоустройства с нуля является значительным усилием. Это требует сильного схватывания Аудиоустройства и Аудио платформы Панели инструментов APIs и Спецификации Аудиоустройства. Однако Core Audio SDK изолирует Вас от большой части этого также. Используя SDK, необходимо реализовать только те методы и свойства, относящиеся к аудиоустройству. (Вы узнаете о механизме свойства аудиоустройства в следующей главе, Аудиоустройстве.)

Открытие и закрытие аудиоустройств

Хост-приложения ответственны — с помощью Менеджера компонентов — для нахождения, открытия и закрытия аудиоустройств. Аудиоустройства, в свою очередь, должны быть findable, открываемыми, и closable. Ваше аудиоустройство получает эти атрибуты, когда Вы создаете его из Core Audio SDK и используете шаблоны аудиоустройства XCode.

Существует двухступенчатая последовательность для аудиоустройства, становящегося доступной для использования в узле. Эти два шага открывают и инициализируют. Открытие аудиоустройства составляет инстанцирование объекта основного класса аудиоустройства. При инициализации сумм к выделению ресурсов, таким образом, аудиоустройство готово выполнить работу.

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

Для больше на открытии, открытие и закрытие с Вашей точки зрения как разработчик аудиоустройства, видят Инициализацию Аудиоустройства и Неинициализацию и Закрывающийся в Аудиоустройстве.

Многократное инстанцирование

Аудиоустройство может инстанцировать любое число раз хост-приложение и любым числом узлов. Более точно Менеджер компонентов вызывает инстанцирование аудиоустройства от имени хост-приложений. Инфраструктура Менеджера компонентов гарантирует, что каждый экземпляр аудиоустройства существует и ведет себя независимо.

Можно продемонстрировать многократное инстанцирование в AU Lab. Сначала добавьте один экземпляр модуля эффекта AUParametricEQ к документу AU Lab, как описано выше в Учебном руководстве: Используя Аудиоустройство в Хост-приложении. Тогда вызовите всплывающие меню в дополнительных строках раздела Effects в дорожке Проигрывателя. Можно добавить столько параметрических эквалайзеров с одной полосой к дорожке, сколько Вам нравится. Каждый из этих экземпляров аудиоустройства ведет себя независимо, как Вы видите варьировавшимися настройками в числе:

Графики обработки аудиоданных и модель приема

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

Когда Вы работали через Учебное руководство: Используя Аудиоустройство в разделе Host Application ранее в этой главе, приложение AU Lab создало график обработки аудиоданных для Вас. Этот график состоял из модуля генератора AUAudioFilePlayer, модуля эффекта AUParametricEQ, и наконец (не представленный в пользовательском интерфейсе AU Lab) предоставленный Apple модуль I/O AUHAL, взаимодействующий через интерфейс с внешними аппаратными средствами, такими как громкоговорители.

Соединения Графика Обработки аудиоданных предоставляют подробную информацию о том, как работают эти соединения.

График Обработки аудиоданных API, объявленный в Аудио платформе Панели инструментов, обеспечивает интерфейсы для помощи хост-приложениям создать и управлять графиками обработки аудиоданных. То, когда хост-приложение использует этот API, оно использует непрозрачный тип данных, вызвало объект диаграмм (типа AUGraph).

Некоторые приложения, такие как AU Lab, всегда используют объекты диаграмм при соединении аудиоустройств. Другие, как Логика, подключают аудиоустройства друг к другу непосредственно. Отдельное аудиоустройство, однако, не знает, управляет ли его соединениями объект диаграмм от имени хост-приложения, или узлом непосредственно.

Аудиоданные текут в доходах графиков от первого (ввод) для длительности (вывод) узла, как Вы ожидали бы. Управление, однако, вытекает из последнего узла назад к первому. В Core Audio это вызывают моделью приема. Хост-приложение отвечает за вызов получения по запросу.

Можно думать о модели приема с точки зрения соломы в стекле воды. Вода в стекле представляет новые аудиоданные, ожидающие, чтобы быть обработанной. Солома представляет график обработки аудиоданных, или даже единственное аудиоустройство. Действуя как хост-приложение, Вы начинаете поток аудиоданных путем «получения по запросу» (потягивающий) на конце соломы. В частности хост-приложение инициирует поток аудиоданных путем вызова метода рендеринга заключительного узла в графике. Каждый глоток, который Вы берете через солому, соответствует другому получению по запросу части кадров аудиоданных — другой вызов к методу рендеринга заключительного узла.

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

Рисунок 1-7 показывает модель приема в особом случае хост-приложения, использующего два модуля эффекта в последовательности.

Вот то, как получение по запросу продолжается на рисунке 1-7:

1. Хост-приложение вызывает метод рендеринга заключительного узла (модуль эффекта B) в графике, прося одну ценность части обработанных кадров аудиоданных.

2. Метод рендеринга модуля эффекта B смотрит в его входных буферах для аудиоданных, чтобы обработать, удовлетворить вызов для рендеринга. Если существуют аудиоданные, ожидающие, чтобы быть обработанными, модуль эффекта B использует их. Иначе, и как показано в числе, модуль эффекта B (использование суперкласса в иерархии классов аудиоустройства SDK’s) вызывает метод рендеринга того, что узел подключил к модулю эффекта вводы B. В этом примере модуль эффекта A подключен к вводам B — таким образом, модуль эффекта B надевает модуль эффекта A, просить аудиоданных части структурирует.

3. Модуль эффекта A ведет себя, как модуль эффекта B делает. Когда этому нужны аудиоданные, это получает его от своего входного соединения, также установленного узлом. Узел подключил модуль эффекта вводы A к обратному вызову рендеринга в узле. Модуль эффекта получения по запросу на обратном вызове рендеринга узла.

4. Обратный вызов рендеринга узла предоставляет требуемые кадры аудиоданных для осуществления модуля A.

5. Модуль эффекта процессы часть данных предоставляется узлом. Модуль эффекта тогда предоставляет обработанные кадры аудиоданных, которые ранее требовали (на шаге 2) к модулю эффекта B.

6. Модуль эффекта B обрабатывает часть данных, предоставленных модулем эффекта A. Модуль эффекта B тогда предоставляет обработанные кадры аудиоданных, которые первоначально требовали (на шаге 1) к хост-приложению. Это завершает один цикл получения по запросу.

Аудиоустройства обычно не знают, подключены ли их вводы и выводы к другим аудиоустройствам, или к хост-приложениям, или к чему-то еще. Аудиоустройства просто реагируют на вызовы рендеринга. Узлы отвечают за установление соединений, и суперклассы (для аудиоустройств, созданных с Core Audio SDK), заботятся о реализации получения по запросу.

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

Обработка: суть дела

Аудиоустройства обрабатывают аудиоданные, конечно. Они также должны знать, как прекратить обрабатывать корректно, и как изменить их обработку на основе пользовательских корректировок. Этот раздел кратко обсуждает эти вещи. Аудиоустройство описывает обработку более подробно.

Поддержка автоматизации параметра

Параметры позволяют пользователям скорректировать аудиоустройства. Например, аудиоустройство фильтра низких частот Apple имеет параметры для частоты отсечки и резонанса.

Автоматизация параметра позволяет пользовательским корректировкам параметра программы вдоль временной шкалы. Например, пользователь мог бы хотеть использовать аудиоустройство фильтра низких частот для обеспечения эффекта как педаль «вау-вау» гитары. С автоматизацией параметра пользователь мог записать wah-wah эффект и сделать его частью музыкального состава. Хост-приложение записывает ручные изменения вместе с информацией о синхронизации, связывая изменения в маркерах времени для аудиотрека. Узел может тогда воспроизвести изменения параметра для обеспечения автоматизированного управления аудиоустройства.

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

Автоматизация параметра полагается на три вещи:

• Возможность аудиоустройства изменить его значения параметров программно по запросу от хост-приложения

• Возможность представления аудиоустройства отправить уведомления как значения параметров изменяется пользователем

• Возможность хост-приложения поддерживать запись и воспроизведение данных автоматизации параметра

Некоторые узлы, поддерживающие автоматизацию параметра с аудиоустройствами, являются Логикой Pro, Ableton Живой, и Metro Sagan.

Автоматизация параметра использует Событие Аудиоустройства API, объявленный в AudioUnitUtilties.h заголовочный файл как часть Аудио платформы Панели инструментов. Этот ориентированный на многопотоковое исполнение API обеспечивает механизм уведомления, поддерживающий аудиоустройства хранения, их представления, и размещающий в синхронизации.

Для поддержки автоматизации параметра в аудиоустройстве необходимо создать пользовательское представление. Вы добавляете поддержку автоматизации исполняемому коду представления, используя Событие Аудиоустройства API для поддержки некоторых или всех следующих типов событий:

• Жесты параметра, включающие kAudioUnitEvent_BeginParameterChangeGesture и kAudioUnitEvent_EndParameterChangeGesture типы событий

• Изменения значения параметра, идентифицированные kAudioUnitEvent_ParameterValueChange тип события

• Изменения свойства, идентифицированные kAudioUnitEvent_PropertyChange тип события

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

Представление Аудиоустройства и Определение и Используя Параметры дают больше информации об автоматизации параметра.

Проверка Аудиоустройства с auval Инструментом

Apple строго рекомендует проверить Ваши аудиоустройства с помощью auval инструмент командной строки во время разработки. auval инструмент (названный как сокращение «проверки аудиоустройства») идет с OS X. Это выполняет всесторонний комплект тестов на:

• Сменный API аудиоустройства, как определено его программируемым типом

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

auval инструмент тестирует только надлежащее аудиоустройство. Это не тестирует ни одного следующего:

• Представления аудиоустройства

• Архитектура аудиоустройства, с точки зрения использования рекомендуемого шаблона разработки контроллера представления модели для разделения проблем

• Корректное использование События Аудиоустройства API

• Качество DSP, качество аудио генерации или качество преобразования формата аудиоданных

auval инструмент может проверить каждый тип аудиоустройства, определенного Apple. При выполнении его это выводит тестовый журнал и суммирует результаты с индикацией «передачи» или "сбоя”.

Для получения дополнительной информации обратитесь к auval встроенная система справочной информации. Видеть auval текст справки, введите следующую команду при подсказке в Терминальном приложении:

auval -h

Тестирование аудиоустройства и хост-приложения

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

• Развитие платформ Core Audio и SDK

• Изменения через версии хост-приложения

• Особенности в реализации некоторых хост-приложений

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

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

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

Тестирование с AU Lab

AU Lab, приложение Вы использовали в Учебном руководстве: Используя Аудиоустройство в Хост-приложении, ссылочный узел аудиоустройства. Это находится в активной разработке командой Core Audio Apple. Они сохраняют его в синхронизации с auval инструмент, с платформами Core Audio и SDK, и с самим OS X. Это делает AU Lab первым местом для тестирования аудиоустройств.

Что можно протестировать с AU Lab

Тестирование Вашего аудиоустройства с AU Lab позволяет Вам протестировать:

• Поведение, с точки зрения того, чтобы быть найденным узлом, выведенным на экран в меню и открытым

• Представление, и универсальное и пользовательское

• Слышимая производительность

• Взаимодействие с другими аудиоустройствами, когда помещено в график обработки аудиоданных

• Возможности I/O, такие как боковые цепи и многократные выводы, а также основное тестирование монофонической и стереофонической работы

В OS X v10.4 «Тигр», AU Lab позволяет Вам протестировать следующие типы аудиоустройств:

• Преобразователи

• Модули эффекта

• Модули генератора

• Модули инструментов

Варьируясь характеристики хост-приложения

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

В AU Lab выберите Preferences из меню AU Lab. Нажмите Devices для показа Предпочтений Устройств:

Щелкните по всплывающему меню Кадров. Можно выбрать число кадров для аудиоустройства для обработки в каждом цикле рендеринга:

Щелкните по треугольнику раскрытия для Опытных Настроек. Можно варьироваться ползунок для выбора процента процессорного времени для посвящения обработке аудиоданных. Это позволяет Вам протестировать поведение своего аудиоустройства при переменных условиях загрузки: