Объемы аудиоустройства

Объем аудиоустройства является программируемым контекстом. В отличие от общего понятия информатики объемов, однако, не могут быть вложены объемы аудиоустройства. Каждый объем является дискретным контекстом.

Вы используете объемы при записи кода, устанавливающего или получающего значения параметров и свойств. Например, Перечисление 2-1 показывает реализацию стандарта GetProperty метод, как используется в модуле эффекта Вы создаете в Учебном руководстве: Создание Простого Модуля Эффекта с Универсальным Представлением:

Перечисление 2-1  Используя «объем» в методе GetProperty

ComponentResult TremoloUnit::GetProperty (

    AudioUnitPropertyID    inID,

    AudioUnitScope         inScope,   // the host specifies the scope

    AudioUnitElement       inElement,

    void                   *outData

) {

    return AUEffectBase::GetProperty (inID, inScope, inElement, outData);

}

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

if (inScope == kAudioUnitScope_Global) {

    // respond to requests targeting the global scope

} else if (inScope == kAudioUnitScope_Input) {

    // respond to requests targeting the input scope

} else {

    // respond to other requests

}

Существует пять объемов, определенных Apple в AudioUnitProperties.h заголовочный файл в платформе Аудиоустройства, показанной в Перечислении 2-2:

  Объемы Аудиоустройства перечисления 2-2

enum {

    kAudioUnitScope_Global   = 0,

    kAudioUnitScope_Input    = 1,

    kAudioUnitScope_Output   = 2,

    kAudioUnitScope_Group    = 3,

    kAudioUnitScope_Part     = 4

};

Три самых важных объема:

• Входной объем: контекст для аудиоданных, входящих в аудиоустройство. Код в аудиоустройстве, хост-приложении или представлении аудиоустройства может адресовать входной объем аудиоустройства для таких вещей как следующее:

  • Аудиоустройство, определяющее дополнительные входные элементы

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

  • Представление аудиоустройства, устанавливающее различные уровни на входе на аудиоустройстве микшера

  • Хост-приложение, подключающее аудиоустройства в график обработки аудиоданных

  Хост-приложения также используют входной объем при регистрации обратного вызова рендеринга, как описано в Соединениях Обратного вызова Рендеринга.

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

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

• Глобальная область видимости: контекст для характеристик аудиоустройства, применяющихся к аудиоустройству в целом. Код в аудиоустройстве адресует свою собственную глобальную область видимости для установки или получения значений таких свойств как:

  • задержка,

  • время хвоста, и

  • поддерживаемое число (ла) каналов.

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

Существует два дополнительных объема аудиоустройства, предназначенные для модулей инструментов, определенных в AudioUnitProperties.h:

• Объем группы: зависящее от контекста к рендерингу музыкальных нот в модулях инструментов

• Объем части: зависящее от контекста к управлению различной речью мультитембральных модулей инструментов

Эта версия Руководства по программированию Аудиоустройства не обсуждает объем группы или объем части.

Элементы аудиоустройства

Элемент аудиоустройства является программируемым контекстом, вкладывающимся в объеме. Обычно, элементы играют роль в объемах ввода и вывода. Здесь, они служат программируемыми аналогами сигнальных шин, используемых в аппаратных аудиоустройствах. Из-за этой аналогии разработчики аудиоустройства часто обращаются к элементам в объемах ввода или вывода как шины; этот документ следует примеру.

Как Вы, возможно, заметили в Перечислении 2-1, узлы указывают элемент, а также объем, для которого они предназначаются при получении или установке свойств или параметров. Вот то, что метод снова с inElement выделенным параметром:

Перечисление 2-3  Используя «элемент» в методе GetProperty

ComponentResult TremoloUnit::GetProperty (

    AudioUnitPropertyID    inID,

    AudioUnitScope         inScope,

    AudioUnitElement       inElement,  // the host specifies the element here

    void                   *outData

) {

    return AUEffectBase::GetProperty (inID, inScope, inElement, outData);

}

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

Глобальная область видимости в аудиоустройстве необычна в этом, она всегда имеет точно один элемент. Поэтому единственный элемент глобальной области видимости всегда является элементом 0.

Шина (т.е. элемент ввода или вывода) всегда имеет точно один потоковый формат. Потоковый формат указывает множество характеристик для шины, включая частоту дискретизации и число каналов. Потоковый формат описан структурой описания аудиопотока (AudioStreamBasicDescription), объявленный в CoreAudioTypes.h заголовочный файл и показанный в Перечислении 2-4:

Перечисление 2-4  структура описания аудиопотока

struct AudioStreamBasicDescription {

    Float64 mSampleRate;        // sample frames per second

    UInt32  mFormatID;          // a four-char code indicating stream type

    UInt32  mFormatFlags;       // flags specific to the stream type

    UInt32  mBytesPerPacket;    // bytes per packet of audio data

    UInt32  mFramesPerPacket;   // frames per packet of audio data

    UInt32  mBytesPerFrame;     // bytes per frame of audio data

    UInt32  mChannelsPerFrame;  // number of channels per frame

    UInt32  mBitsPerChannel;    // bit depth

    UInt32  mReserved;          // padding

};

typedef struct AudioStreamBasicDescription AudioStreamBasicDescription;

Аудиоустройство может позволить хост-приложению получить и установить потоковые форматы своих шин с помощью kAudioUnitProperty_StreamFormat свойство, объявленное в AudioUnitProperties.h заголовочный файл. Значение этого свойства является структурой описания аудиопотока.

Как правило, Вам будут нужны просто единственная входная шина и единственная выходная шина в аудиоустройстве. Когда Вы создаете модуль эффекта путем разделения на подклассы AUEffectBase класс, Вы получаете ввод того и одну выходную шину по умолчанию. Ваше аудиоустройство может указать дополнительные шины путем переопределения конструктора основного класса. Вы тогда указали бы дополнительные шины с помощью kAudioUnitProperty_BusCount свойство или его синоним kAudioUnitProperty_ElementCount, оба объявленные в AudioUnitProperties.h заголовочный файл.

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

Шина может иметь точно одно соединение, как описано затем.

Соединения аудиоустройства

Соединение является рукой - от точки для ввода аудиоданных или отъезда аудиоустройства. Когда аудиоустройство вызывает обратный вызов рендеринга, новые выборки аудиоданных перемещаются через соединение и в аудиоустройство. Когда метод рендеринга аудиоустройства вызывают, обработанные выборки аудиоданных оставляют аудиоустройство. Core Audio иерархия классов SDK’s реализует руку аудиоданных - прочь, работающий с кодом рендеринга аудиоустройства.

Узлы устанавливают соединения при гранулярности шины, а не отдельных каналов. Вы видите это на рисунке 2-1. Число каналов в соединении определяется потоковым форматом, установленным для шины, содержащей соединение.

typedef struct AudioUnitConnection {

    AudioUnit sourceAudioUnit;    // the audio unit that supplies audio

                                  //    data to the audio unit whose

                                  //    connection property is being set

    UInt32    sourceOutputNumber; // the output bus of the source unit

    UInt32    destInputNumber;    // the input bus of the destination unit

} AudioUnitConnection;

typedef OSStatus (*AURenderCallback)(

    void                          *inRefCon,

    AudioUnitRenderActionFlags    *ioActionFlags,

    const AudioTimeStamp          *inTimeStamp,

    UInt32                        inBusNumber,

    UInt32                        inNumberFrames,

    AudioBufferList               *ioData

);

extern ComponentResult AudioUnitRender (

    AudioUnit                     ci,

    AudioUnitRenderActionFlags    *ioActionFlags,

    const AudioTimeStamp          *inTimeStamp,

    UInt32                        inOutputBusNumber,

    UInt32                        inNumberFrames,

    AudioBufferList               *ioData

);

Каналы аудиоустройства

Канал аудиоустройства является, концептуально, монофоническим, нечередующимся путем для выборок аудиоданных, переходящим в или от кода обработки аудиоустройства. Core Audio SDK представляет каналы как буферы. Каждый буфер описан аудио буферной структурой (AudioBuffer), как объявлено в CoreAudioTypes.h заголовочный файл в платформе Core Audio, как показано в Перечислении 2-8:

Перечисление 2-8  аудио буферная структура

struct AudioBuffer {

    UInt32  mNumberChannels; // number of interleaved channels in the buffer

    UInt32  mDataByteSize;   // size, in bytes, of the buffer

    void    *mData;          // pointer to the buffer

};

typedef struct AudioBuffer AudioBuffer;

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

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

Аудиоустройство управляет набором каналов в шине как аудио буферная структура списка (AudioBufferList), также определенный в CoreAudioTypes.h, как показано в Перечислении 2-9:

Перечисление 2-9  аудио буферная структура списка

struct AudioBufferList {

    UInt32      mNumberBuffers;  // the number of buffers in the list

    AudioBuffer mBuffers[kVariableLengthArray]; // the list of buffers

};

typedef struct AudioBufferList  AudioBufferList;

В общем падеже создания модуля эффекта канала n-to-n такого как тот Вы создаете в Учебном руководстве: Создавая Простой Модуль Эффекта с Универсальным Представлением, шаблон аудиоустройства и суперклассы заботятся об управлении каналами для Вас. Вы создаете этот тип модуля эффекта путем разделения на подклассы AUEffectBase класс в SDK.

Напротив, при создании модуля эффекта канала m-to-n (например, stereo-mono модуль эффекта), необходимо записать код для управления каналами. В этом случае Вы создаете свой модуль эффекта путем разделения на подклассы AUBase класс. (Как с остальной частью этого документа, это рассмотрение применяется к версии 1.4.3 Core Audio SDK, текущий во время публикации.)

Определяя и Используя параметры

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

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

GetParameterInfo метод можно вызвать:

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

• Хост-приложением, обеспечивающим универсальное представление для аудиоустройства

• Хост-приложением, представляющим параметры аудиоустройства на аппаратной поверхности управления

Для использования текущей установки параметра (как скорректировано пользователем) при рендеринге аудио Вы вызываете GetParameter метод. Этот метод наследован от AUEffectBase класс.

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

В дополнение к GetParameterInfo метод (для сообщения представления или узла о текущей стоимости параметра) и GetParameter метод (для использования значения параметра во время рендеринга), аудиоустройству нужен способ установить его значения параметров. Для этого это обычно использует SetParameter метод, от AUEffectBase класс.

Существуют два основных раза вызовы аудиоустройства SetParameter метод:

• Во время инстанцирования — в его методе конструктора — для установки его значений параметров по умолчанию

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

SetParameter метод берет два параметра метода — ID параметра, который будет изменен и его новое значение, как показано в Перечислении 2-10:

Перечисление 2-10  метод SetParameter

void SetParameter(

    UInt32 paramID,

    Float32 value

);

Аудиоустройство Вы создаете в Учебном руководстве: Создание Простого Модуля Эффекта с Универсальным Представлением использует все три из этих методов: GetParameterInfo, GetParameter, и SetParameter.

Аудиоустройство иногда должно вызывать изменение значения для одного из его параметров. Это могло бы сделать это в ответ на изменение (вызванный представлением или узлом) в другом параметре. Когда аудиоустройство по его собственной инициативе изменяет значение параметра, оно должно отправить уведомление о событии.

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

Предварительные установки фабрики и персистентность параметра

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

Например, модуль Реверберации Матрицы OS X содержит больше чем дюжину параметров. Пользователь мог найти установку их в полезном укрощении комбинаций. Разработчики Матричной Реверберации приняли это во внимание и обеспечили широкий диапазон предварительных установок фабрики с очень описательными именами, такими как Небольшая комната, Крупный Холл и Собор.

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

Когда пользователь выбирает предварительную установку фабрики, представление вызывает аудиоустройство NewFactoryPresetSet метод. Вы определяете этот метод параллельно с GetPresets метод. Для каждой предварительной установки Вы предлагаете в предварительно установленном меню фабрики, Вы включаете код в NewFactoryPresetSet метод для установки той предварительной установки, когда пользователь запрашивает его. Для каждой предварительной установки фабрики этот код состоит из серии SetParameter вызовы метода. См. Учебное руководство: Создание Простого Модуля Эффекта с Универсальным Представлением для поэтапного руководства при реализации предварительных установок фабрики.

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

Разработчики хост-приложения обеспечивают персистентность параметра путем использования в своих интересах SDK’s kAudioUnitProperty_ClassInfo свойство. Это свойство использует a CFPropertyListRef словарь для представления текущих настроек аудиоустройства.

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

Существует больше чем 100 определенных Apple свойств, доступных для аудиоустройств. Вы находите их объявления в AudioUnitProperties.h заголовочный файл в платформе Аудиоустройства. Каждый тип аудиоустройства имеет ряд требуемых свойств, как описано в Спецификации Аудиоустройства.

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

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

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

Например, kAudioUnitProperty_StreamFormat свойство, описывающее формат потока аудиоданных аудиоустройства, хранит свое значение в AudioStreamBasicDescription структура. Эта структура объявляется в CoreAudioTypes.h заголовочный файл в CoreAudio платформа.

AUBase суперкласс обеспечивает общее получение и установку методов, которые можно переопределить для реализации свойств, как описано в Определении Пользовательских Свойств. Эти методы, GetPropertyInfo, GetProperty, и SetProperty, работа со связанными методами «отгрузки» в SDK, который Вы не вызываете непосредственно. Методы отгрузки, такой как DispatchGetPropertyInfo, обеспечьте большую часть волшебства свойства аудиоустройства для SDK. Можно исследовать их в AUBase.cpp файл в SDK для наблюдения то, что они делают.

AUEffectBase класс, MusicDeviceBase класс и другие подклассы переопределяют методы доступа свойства с кодом для свойств, определенных для одного типа аудиоустройства. Например, AUEffectBase класс обрабатывает вызовы свойства, которые являются определенными для модулей эффекта, такой как kAudioUnitProperty_BypassEffect свойство.

virtual ComponentResult GetPropertyInfo (

    AudioUnitPropertyID  inID,

    AudioUnitScope       inScope,

    AudioUnitElement     inElement,

    UInt32               &outDataSize,

    Boolean              &outWritable);

virtual ComponentResult GetProperty (

    AudioUnitPropertyID  inID,

    AudioUnitScope       inScope,

    AudioUnitElement     inElement,

    void                 *outData);

Обработка сигналов

Для выполнения DSP Вы используете модуль эффекта (типа 'aufx'), обычно созданный как подкласс AUEffectBase класс. AUEffectBase использует класс помощника для обработки DSP, AUKernelBase, и инстанцирует одного объекта ядра (AUKernelBase) для каждого звукового канала.

Объекты ядра являются определенными для модулей эффекта канала n-to-n, разделенных на подклассы от AUEffectBase класс. Они не часть других типов аудиоустройств.

AUEffectBase класс является строго для создания n-to-n модулями эффекта канала. Если Вы создаете модуль эффекта, не использующий прямое отображение ввода к каналам вывода, Вы разделяете на подклассы AUBase суперкласс вместо этого.

Как описано в Обработке: Суть дела, существует два основных метода для аудиоустройства код DSP: Process и Reset. Вы переопределяете Process метод для определения DSP для аудиоустройства. Вы переопределяете Reset метод для определения очистки для выполнения, когда пользователь принимает меры для окончания обработки сигналов, такой как перемещение точки воспроизведения в окне звукового редактора. Например, Вы гарантируете Reset то, что затухание реверберации не вмешивается в запуск игры в новой точке в звуковом файле.

Учебное руководство: Создание Простого Модуля Эффекта с Универсальным Представлением обеспечивает поэтапный пример реализации a Process метод.

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

Аудиоустройства создали использование классов в Core Audio работа SDK только с аудиоданными с постоянной скоростью передачи (CBR). Когда хост-приложение считывает данные с переменной скоростью передачи (VBR), оно преобразовывает его в представление CBR, в форме линейного PCM, прежде, чем отправить его в аудиоустройство.

Музыкальный синтез

Модуль инструментов (типа 'aumu'), в отличие от модуля эффекта, аудио рендеринга с точки зрения примечаний. Это действует как виртуальный музыкальный синтезатор. Модуль инструментов нанимает банк звуков и реагирует на управляющую информацию MIDI, обычно инициируемую клавиатурой.

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

Core Audio иерархия классов SDK также обеспечивает AUMultitimbralInstrumentBase класс. Этот класс поддерживает монофонические и полифонические модули инструментов, которые могут играть больше чем одну речь за один раз. Например, Вы могли создать multimbral модуль инструментов, который позволит пользователю играть на виртуальной бас-гитаре с их левой рукой при игре виртуальной трубы с их правой рукой, использовании единственной клавиатуры.

Музыкальные эффекты

Музыкальный модуль эффекта (типа 'aumf') обеспечивает DSP, как модуль эффекта, но также и реагирует на данные MIDI, как модуль инструментов. Вы создаете музыкальный модуль эффекта путем разделения на подклассы AUMIDIEffectBase суперкласс от SDK. Например, Вы сделали бы это для создания аудиоустройства, обеспечивающего эффект фильтрации, настраивающийся согласно примечанию, нажатому на клавиатуре.

Преобразование формата данных

Трансформации аудиоданных включают такие операции как преобразование частоты дискретизации, отправляя сигнал многократным местам назначения, и изменяя время или подачу. Для преобразования аудиоданных способами, такими как они Вы создаете модуль преобразователя форматов (типа 'aufc') как подкласс AUBase суперкласс в SDK.

Аудиоустройства не предназначаются для работы с переменной скоростью передачи (VBR) данных, таким образом, аудиоустройства обычно не подходят для преобразования в или от форматов сжатия с потерями, таких как MP3. Для работы с форматами сжатия с потерями используйте Аудио Преобразователь Core Audio API, объявленный в AudioConverter.h заголовочный файл в Аудио платформе Панели инструментов.

Обзор

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

• Менеджер компонентов OS X, действующий от имени хост-приложения

• Само хост-приложение

• График обработки аудиоданных и, в частности нисходящее аудиоустройство

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

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

Жизненный цикл аудиоустройства продолжается через серию состояний, включающих:

• Неинстанцированный. В этом состоянии нет никакого экземпляра объекта аудиоустройства, но присутствие класса аудиоустройства в системе регистрируется Менеджером компонентов. Хост-приложения используют реестр Менеджера компонентов, чтобы найти и открыть аудиоустройства.

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

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

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

Категории программируемых событий

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

• События обслуживания, которые инициирует хост-приложение. Они включают открытие, открытие, проверку, соединение и закрытие аудиоустройств. Для этих типов событий аудиоустройство создало из Core Audio, SDK обычно полагается на код в его предоставленных суперклассах.

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

Реализовывание аудиоустройства

Даже перед инстанцированием, аудиоустройство имеет своего рода призрачное присутствие в OS X. Это вызвано тем, что во время пользовательского входа в систему, Менеджер компонентов создает список доступных аудиоустройств. Это делает это, не открывая их. Хост-приложения могут тогда найти и открыть аудиоустройства с помощью Менеджера компонентов.

Жизнь начинается для аудиоустройства, когда хост-приложение просит, чтобы Менеджер компонентов инстанцировал ее. Это обычно происходит, когда хост-приложение запускается — в котором времени узел обычно инстанцирует каждого установленного аудиоустройства. Узлы, такие как AU Lab и Логика Pro делают это, например, для приобретения знаний о форматах потока данных ввода и вывода, а также числе вводов и выводов для каждого установленного аудиоустройства. Узлы обычно кэшируют эту информацию и затем закрывают аудиоустройства.

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

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

N-канал к модулю эффекта n-канала (созданный из AUEffectBase класс), не инстанцирует его объекта ядра или возражает, пока не инициализируется аудиоустройство. Поэтому и для этого типа аудиоустройства, является надлежащим выполнить ресурсоемкую работу, такую как установка звуковых таблиц, во время инстанцирования ядра. Для больше на этом, посмотрите Инстанцирование Ядра в n-to-n Модулях Эффекта.

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

Конфигурация свойства

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

• Самим аудиоустройством, обычно во время инстанцирования

• Приложением, размещающим аудиоустройство, прежде или после инициализации аудиоустройства

• Представлением аудиоустройства, как управляется пользователем, когда аудиоустройство инициализируется или неинициализированное

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

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

Для других свойств, такой как kAudioUnitProperty_SetRenderCallback свойство, спецификация аудиоустройства мешает узлам изменять свойство на инициализированном аудиоустройстве, но нет никакого программируемого осуществления против него.

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

Спецификация аудиоустройства детализирует требования конфигурации для определенного свойства каждого Apple.

Инициализация аудиоустройства и неинициализация

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

Вот некоторые примеры работы, это является надлежащим в течение времени инициализации:

• Модуль инструментов получает банк звуков MIDI для модуля для использования при ответе на данные MIDI

• Модуль эффекта выделяет буферы памяти для использования во время рендеринга

• Модуль эффекта вычисляет звуковые таблицы для использования во время рендеринга

Вообще говоря, каждая из этих операций должна быть выполнена в переопределении Initialize метод от AUBase класс.

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

При установке внутренних буферов для обработки можно узнать как большой для создания их путем вызова AUBase::GetMaxFramesPerSlice метод. Это получает доступ к значению, которое определяет хост-приложение Вашего аудиоустройства, прежде чем оно вызовет инициализацию. Фактическое число кадров на вызов рендеринга может варьироваться. Это установлено хост-приложением при помощи inFramesToProcess параметр AUEffectBase::Process или AUBase::DoRender методы.

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

Иерархия классов аудиоустройства в Core Audio SDK обеспечивает специализированный Initialize методы для различных типов аудиоустройств. Модули эффекта, например, используют Initialize метод в AUEffectBase класс. Этот метод выполняет много важных задач по обслуживанию, включая:

• Защита модуля эффекта против хост-приложения, пытающегося соединить его способами, которые не будут работать

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

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

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

Во многих случаях такой как в модуле эффекта Вы создадите в Учебном руководстве: Создавая Простой Модуль Эффекта с Универсальным Представлением, модулям эффекта не нужна дополнительная работа инициализации в классе аудиоустройства. Они могут просто использовать Initialize метод от AUBase как, наследованием. Модуль эффекта, который Вы создадите в учебном руководстве, делает это.

В конкретном случае модуля эффекта на основе AUEffectBase суперкласс, можно поместить ресурсоемкий код инициализации в конструктора для объекта ядра DSP. Это работает, потому что ядра инстанцируют во время инициализации модуля эффекта. Модуль эффекта в качестве примера, который Вы создаете позже в этом документе, описывает эту часть жизненного цикла модуля эффекта.

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

Инстанцирование ядра в n-to-n Модулях Эффекта

В эффекте модуль создал использование AUEffectBase суперкласс — такой как модуль тремоло, который Вы создаете в учебном руководстве по модулю эффекта — обработка, имеет место в одном или более так называемых объектах ядра. Эти объекты разделяются на подклассы от AUKernelBase класс, как описано в Реализовывании Аудиоустройства.

Такие модули эффекта инстанцируют одного объекта ядра для каждого используемого канала. Инстанцирование объекта ядра имеет место во время инициализации аудиоустройства как часть этой последовательности:

1. N-канал к модулю эффекта n-канала инстанцируют

2. Модуль эффекта инициализируется

3. Во время инициализации модуль эффекта инстанцирует надлежащего числа объектов ядра

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

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

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

Взаимодействия аудиоустройства с графиком обработки аудиоданных включают:

• Установление соединений ввода и вывода

• Повреждение соединений ввода и вывода

• Ответ на запросы рендеринга

Хост-приложение ответственно за то, что сделало и повредило соединения для графика обработки аудиоданных. Выполнение соединения и разъединения имеет место посредством установки свойств, как обсуждено ранее в этой главе в Соединениях Графика Обработки аудиоданных. Для аудиоустройства, которое будет добавлено к или удалено из графика, это должно быть неинициализированным.

Аудиоданные текут в доходах графиков согласно модели приема, как описано в Графиках Обработки аудиоданных и Модели приема.

Обработка аудиоустройства

В зависимости от его типа выполняет одно из следующих действий: аудиоустройство

• Аудио процессов (например, модули эффекта и музыкальные модули эффекта)

• Генерирует аудио от данных MIDI (модули инструментов) или иначе, такой как путем чтения файла (модули генератора)

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

В действительности модули создали использование Core Audio SDK, работа обработки имеет место в вызванном методе C++ Process. Этот метод, от AUKernelBase класс, объявляется в AUEffectBase.h заголовочный файл в SDK. В модулях инструментов созданное использование SDK аудио работа генерации имеет место в вызванном методе Render, определенный в AUInstrumentBase класс.

Когда модуль принимает вызов к, в модуле эффекта запускается обработка Process метод. Этот вызов обычно прибывает из нисходящего аудиоустройства в графике обработки аудиоданных. Как описано во Взаимодействиях Графика Обработки аудиоданных, вызов является результатом каскада, происходящего из хост-приложения посредством объекта диаграмм, прося, чтобы запустился заключительный узел в графике.

Вызов обработки, который принимает аудиоустройство, указывает буферы ввода и вывода, а также объем данных для обработки:

Перечисление 2-13  метод Процесса от класса AUKernelBase

virtual void Process (

    const Float32    *inSourceP,

    Float32          *inDestP,

    UInt32           inFramesToProcess,

    UInt32           inNumChannels,

    bool &           ioSilence) = 0;

Для реализации в качестве примера метода Процесса см. Учебное руководство: Создание Простого Модуля Эффекта с Универсальным Представлением.

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

• Взаимоисключающий (взаимное исключение) блокировка ресурса

• Выделение памяти или распределение ресурсов

Закрытие

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

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