Аудиоустройства в iOS

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

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

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

iOS имеет один API для работы с аудиоустройствами непосредственно и другим для управления графиками обработки аудиоданных. При хостинге аудиоустройств в приложении Вы используете оба APIs в согласии.

• Для работы с аудиоустройствами непосредственно — конфигурированием и управлением ими — используют функции, описанные в Ссылке Audio Unit Component Services.

• Чтобы создать и сконфигурировать график обработки аудиоданных (цепочка обработки аудиоустройств) используют функции, описанные в Ссылке Audio Unit Processing Graph Services.

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

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

• Инстанцирование аудиоустройств

• Соединение аудиоустройств и присоединение функций обратного вызова рендеринга

• Запуск и остановка аудио потока

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

Используйте идентификаторы, чтобы указать и получить аудиоустройства

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

Перечисление 1-1  , Создающее аудио описание компонента для идентификации аудиоустройство

AudioComponentDescription ioUnitDescription;

ioUnitDescription.componentType          = kAudioUnitType_Output;

ioUnitDescription.componentSubType       = kAudioUnitSubType_RemoteIO;

ioUnitDescription.componentManufacturer  = kAudioUnitManufacturer_Apple;

ioUnitDescription.componentFlags         = 0;

ioUnitDescription.componentFlagsMask     = 0;

Это описание указывает точно одно аудиоустройство — Удаленный модуль I/O. Ключи для этого и других аудиоустройств iOS перечислены в Ключах Идентификатора для Аудиоустройств. Обратите внимание на то, что все аудиоустройства iOS используют kAudioUnitManufacturer_Apple ключ для componentManufacturer поле.

Для создания подстановочного описания установите один или больше полей типа/подтипа к 0. Например, для соответствия всех модулей I/O измените Перечисление 1-1 для использования значения 0 для componentSubType поле.

С описанием в руке Вы получаете ссылку на библиотеку для указанного аудиоустройства (или набор аудиоустройств) использующий любой из двух APIs. Аудиоустройство API показано в Перечислении 1-2.

Перечисление 1-2  Получая экземпляр аудиоустройства с помощью аудиоустройства API

AudioComponent foundIoUnitReference = AudioComponentFindNext (

                                          NULL,

                                          &ioUnitDescription

                                      );

AudioUnit ioUnitInstance;

AudioComponentInstanceNew (

    foundIoUnitReference,

    &ioUnitInstance

);

Передача NULL к первому параметру AudioComponentFindNext говорит этой функции находить первое системное аудиоустройство, соответствующее описание, с помощью определенного с помощью системы упорядочивания. Если Вы вместо этого передаете ранее найденную ссылку аудиоустройства в этом параметре, функция определяет местоположение следующего аудиоустройства, соответствующего описание. Это использование позволяет, Вы, например, получаете ссылки на все модули I/O путем повторного вызова AudioComponentFindNext.

Второй параметр к AudioComponentFindNext вызов обращается к описанию аудиоустройства, определенному в Перечислении 1-1.

Результат AudioComponentFindNext функция является ссылкой на динамично связываемую библиотеку, определяющую аудиоустройство. Передайте ссылку на AudioComponentInstanceNew функция для инстанцирования аудиоустройства, как показано в Перечислении 1-2.

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

Перечисление 1-3  Получая экземпляр аудиоустройства с помощью графика обработки аудиоданных API

// Declare and instantiate an audio processing graph

AUGraph processingGraph;

NewAUGraph (&processingGraph);

// Add an audio unit node to the graph, then instantiate the audio unit

AUNode ioNode;

AUGraphAddNode (

    processingGraph,

    &ioUnitDescription,

    &ioNode

);

AUGraphOpen (processingGraph); // indirectly performs audio unit instantiation

// Obtain a reference to the newly-instantiated I/O unit

AudioUnit ioUnit;

AUGraphNodeInfo (

    processingGraph,

    ioNode,

    NULL,

    &ioUnit

);

Этот листинг кода представляет AUNode, непрозрачный тип, представляющий аудиоустройство в контексте графика обработки аудиоданных. Вы получаете ссылку на новый экземпляр аудиоустройства, в ioUnit параметре, на выводе AUGraphNodeInfo вызов функции.

Второй параметр к AUGraphAddNode вызов обращается к описанию аудиоустройства, определенному в Перечислении 1-1.

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

Используйте объемы и элементы для указания частей аудиоустройств

Части аудиоустройства организованы в объемы и элементы, как показано на рисунке 1-2. При вызове функции, чтобы сконфигурировать или управлять аудиоустройством, Вы указываете объем и элемент для идентификации определенной цели функции.

Объем является программируемым контекстом в аудиоустройстве. Несмотря на то, что глобальная область видимости имени могла бы предложить иначе, эти контексты никогда не вкладываются. Вы указываете объем, для которого Вы предназначаетесь при помощи константы от Audio Unit Scopes перечисление.

Элемент является программируемым контекстом, вложенным в объеме аудиоустройства. Когда элемент является частью объема ввода или вывода, это походит на сигнальную шину в физическом аудиоустройстве — и по этой причине иногда вызывается шиной. Эти два условия — элемент и шина — относятся к точно той же вещи в программировании аудиоустройства. Эта «шина» использования документа при подчеркивании потока сигналов и использования «элемент» при подчеркивании определенного функционального аспекта аудиоустройства, такой элементы ввода и вывода модуля I/O (см. Существенные Характеристики Модулей I/O).

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

Рисунок 1-2 иллюстрирует одну общую архитектуру для аудиоустройства, в котором числа элементов на вводе и выводе являются тем же. Однако различные аудиоустройства используют различную архитектуру. Модуль микшера, например, мог бы иметь несколько входных элементов, но единственный выходной элемент. Можно расширить то, что Вы узнаете здесь об объемах и элементах к любому аудиоустройству, несмотря на эти изменения в архитектуре.

Глобальная область видимости, показанная у основания рисунка 1-2, применяется к аудиоустройству в целом и не связана ни с каким определенным аудиопотоком. Это имеет точно один элемент, а именно, элемент 0. Некоторые свойства, такие как максимум структурирует на часть (kAudioUnitProperty_MaximumFramesPerSlice), применяйтесь только к глобальной области видимости.

Объемы ввода и вывода участвуют непосредственно в перемещении того или большего количества аудиопотоков через аудиоустройство. Как Вы ожидали бы, аудио входит во входном объеме и листах в выходном объеме. Свойство или параметр могут примениться к объему ввода или вывода в целом, как имеет место для свойства количества элемента (kAudioUnitProperty_ElementCount), например. Другие свойства и параметры, такие как разрешать свойство I/O (kAudioOutputUnitProperty_EnableIO) или параметр объема (kMultiChannelMixerParam_Volume), применитесь к определенному элементу в объеме.

Используйте свойства для конфигурирования аудиоустройств

Свойство аудиоустройства является парой ключ/значение, которую можно использовать для конфигурирования аудиоустройства. Ключ для свойства является уникальным целым числом со связанным мнемоническим идентификатором, такой как kAudioUnitProperty_MaximumFramesPerSlice = 14. Apple резервирует ключи свойства от 0 до 63999. В Mac OS X сторонние аудиоустройства используют ключи выше этого диапазона.

Значение для каждого свойства имеет определяемый тип данных и имеет определяемый доступ для чтения-записи, как описано в Ссылке Свойств Аудиоустройства. Для установки любого свойства на любом аудиоустройстве Вы используете одну гибкую функцию: AudioUnitSetProperty. Перечисление 1-4 показывает типичное использование этой функции с выделением комментариев, как указать объем и элемент, а также указание ключа и оценить за свойство.

Перечисление 1-4  Используя объем и элемент при установке свойства

UInt32 busCount = 2;

OSStatus result = AudioUnitSetProperty (

    mixerUnit,

    kAudioUnitProperty_ElementCount,   // the property key

    kAudioUnitScope_Input,             // the scope to set the property on

    0,                                 // the element to set the property on

    &busCount,                         // the property value

    sizeof (busCount)

);

Вот несколько свойств, которые Вы будете часто использовать в разработке аудиоустройства. Познакомьтесь с каждым из них путем чтения его справочной документации и путем исследования проектов примера кода аудиоустройства Apple, таких как Аудио Микшер (MixerHost):

• kAudioOutputUnitProperty_EnableIO, для включения или отключения ввода или вывода на модуле I/O. По умолчанию вывод включен, но введен, отключен.

• kAudioUnitProperty_ElementCount, для конфигурирования числа входных элементов на модуле микшера, например.

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

• kAudioUnitProperty_StreamFormat, для указания формата данных аудиопотока для определенной шины ввода или вывода аудиоустройства.

Большинство значений свойств может быть установлено только, когда аудиоустройство является неинициализированным. Такие свойства не предназначаются, чтобы быть измененными пользователем. Некоторые, тем не менее, такой как kAudioUnitProperty_PresentPreset свойство iPod модуль EQ, и kAUVoiceIOProperty_MuteOutput свойство Обработки речи модуль I/O, предназначаются, чтобы быть измененным при игре аудио.

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

• AudioUnitGetPropertyInfo— Обнаружить, доступно ли свойство; если это, Вам дают размер данных для его значения и можно ли изменить значение

• AudioUnitGetProperty, AudioUnitSetProperty— Получить или установить значение свойства

• AudioUnitAddPropertyListener, AudioUnitRemovePropertyListenerWithUserData— Установить или удалить функцию обратного вызова для того, чтобы наблюдать изменения к значению свойства

Используйте параметры и UIKit для предоставления пользовательского контроля

Параметр аудиоустройства является корректируемой пользователем установкой, которая может измениться, в то время как аудиоустройство производит аудио. Действительно, намерение большинства параметров (таких как объем или позиция панорамирования стерео) является корректировкой в реальном времени обработки, которую выполняет аудиоустройство.

Как свойство аудиоустройства, параметр аудиоустройства является парой ключ/значение. Ключ определяется аудиоустройством, которому он применяется к. Это всегда - постоянное перечисление, такой как kMultiChannelMixerParam_Pan = 2, это уникально для аудиоустройства, но не глобально уникально.

В отличие от значений свойств, каждое значение параметра имеет тот же тип: 32-разрядная плавающая точка. Допустимый диапазон для значения и единица измерения, которую это представляет, определяются реализацией аудиоустройства параметра. Эти и другие аспекты параметров в аудиоустройствах iOS описаны в Ссылке Параметров Аудиоустройства.

Чтобы получить или установить значение параметра, используйте одну из следующих функций, полностью описанных в Ссылке Audio Unit Component Services:

• AudioUnitGetParameter

• AudioUnitSetParameter

Чтобы позволить пользователям управлять аудиоустройством, предоставьте им доступ к его параметрам посредством пользовательского интерфейса. Запустите путем выбора надлежащего класса из платформы UIKit для представления параметра. Например, для функции включения - выключения, такой как Многоканальный модуль Микшера kMultiChannelMixerParam_Enable параметр, Вы могли использовать a UISwitch объект. Для постоянно переменной функции, такой как позиция панорамирования стерео в соответствии с kMultiChannelMixerParam_Pan параметр, Вы могли использовать a UISlider объект.

Передайте значение текущей конфигурации объекта UIKit — такой как позиция ползунка ползунка для a UISlider— к аудиоустройству. Сделайте так путем обертывания AudioUnitSetParameter функция в IBAction метод и установление соответствующего соединения в Интерфейсном Разработчике. Для примера кода, иллюстрирующего, как сделать это, см. проект примера кода Аудио Микшер (MixerHost).

Существенные характеристики модулей I/O

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

Модуль I/O содержит точно два элемента, как Вы видите на рисунке 1-3.

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

Элемент 1 из модуля I/O соединяется непосредственно с аппаратными средствами аудиовхода на устройстве, представленном в числе микрофоном. Это аппаратное соединение — во входном объеме элемента 1 — непрозрачно Вам. Ваш первый доступ к аудиоданным, входящим от входных аппаратных средств, в выходном объеме элемента 1.

Точно так же элемент 0 из модуля I/O подключает непосредственно аппаратные средства аудиовыхода на устройстве, представленном на рисунке 1-3 громкоговорителем. Можно передать аудио входному объему элемента 0, но его выходной объем непрозрачен.

Работая с аудиоустройствами, Вы будете часто слышать два элемента модуля I/O, описанного не их числами, но по имени:

• Входной элемент является элементом 1 (мнемоническое устройство: буква у «меня» слова «Input» есть появление, подобное номеру 1),

• Выходной элемент является элементом 0 (мнемоническое устройство: буква «O» слова «Output» имеет появление, подобное номеру 0),

Как Вы видите на рисунке 1-3, каждый элемент сам имеет входной объем и выходной объем. Поэтому описание этих частей модуля I/O может стать немного запутывающим. Например, Вы сказали бы, что в одновременном приложении I/O, получаете аудио от выходного объема входного элемента и отправляете аудио во входной объем выходного элемента. Когда Вы должны будете, возвратитесь к этому числу.

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

График обработки аудиоданных имеет точно один модуль I/O

Каждый график обработки аудиоданных имеет один модуль I/O, делаете ли Вы запись, воспроизведение или одновременный I/O. Модуль I/O может быть любым из доступных в iOS, в зависимости от потребностей Вашего приложения. Для получения дополнительной информации о том, как модули I/O вписываются в архитектуру графика обработки аудиоданных в различных сценариях использования, посмотрите, Запускаются путем Выбора Design Pattern.

Графики позволяют Вам запустить и остановить поток аудио посредством AUGraphStart и AUGraphStop функции. Эти функции, в свою очередь, передайте запуск или сообщение остановки к модулю I/O путем вызова AudioOutputUnitStart или AudioOutputUnitStop функция. Таким образом модуль I/O графика отвечает за аудио поток в графике.

Графики обработки аудиоданных обеспечивают потокобезопасность

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

Вот некоторые общие реконфигурирования, поддерживаемые графиком обработки аудиоданных API, вместе с их присоединенными функциями:

• Добавление или удаление узлов аудиоустройства (AUGraphAddNode, AUGraphRemoveNode)

• Добавление или удаление соединений между узлами (AUGraphConnectNodeInput, AUGraphDisconnectNodeInput)

• Соединение функции обратного вызова рендеринга к входной шине аудиоустройства (AUGraphSetNodeInputCallback)

Давайте смотреть на пример реконфигурирования рабочего графика обработки аудиоданных. Скажите, например, Вы создали график, включающий Многоканальный модуль Микшера и Удаленный модуль I/O для смешанного воспроизведения двух синтезируемых звуков. Вы подаете звуки к двум входным шинам микшера. Вывод микшера переходит к выходному элементу модуля I/O и на выходных аппаратных средствах аудио. Рисунок 1-4 изображает эту архитектуру.

Теперь, скажите, что пользователь хочет вставить эквалайзер в один из этих двух аудиопотоков. Чтобы сделать это, добавьте iPod модуль EQ между каналом одного из звуков и вводом микшера, что это переходит в, как показано на рисунке 1-5.

Шаги для выполнения этого живого реконфигурирования следующие:

1. Разъедините “обратный вызов” звука ударов от ввода 1 из модуля микшера путем вызова AUGraphDisconnectNodeInput.

2. Добавьте узел аудиоустройства, содержащий iPod модуль EQ к графику. Сделайте это путем указания iPod модуль EQ с AudioComponentDescription структура, затем вызывая AUGraphAddNode. В этой точке iPod модуль EQ инстанцируют, но не инициализируют. Это принадлежит графику, но еще не участвует в аудио потоке.

3. Сконфигурируйте и инициализируйте iPod модуль EQ. В этом примере это влечет за собой несколько вещей:

   • Вызовите AudioUnitGetProperty функция для получения потокового формата (kAudioUnitProperty_StreamFormat) от ввода микшера.

   • Вызовите AudioUnitSetProperty функционируйте дважды, один раз для установки того потокового формата на iPod ввод модуля EQ и во второй раз для установки его на выводе. (Для полного описания того, как сконфигурировать iPod модуль EQ, посмотрите Используя Модули Эффекта.)

   • Вызовите AudioUnitInitialize функция, чтобы выделить ресурсы для iPod модуль EQ и подготовить его для обработки аудио. Этот вызов функции не ориентирован на многопотоковое исполнение, но Вы можете (и должен) выполнять его в этой точке в последовательности, когда iPod, модуль EQ еще не участвует активно в графике обработки аудиоданных, потому что Вы еще не вызвали AUGraphUpdate функция.

4. Присоедините “функцию обратного вызова” звука ударов к вводу iPod EQ путем вызова AUGraphSetNodeInputCallback.

В предыдущем списке, шагах 1, 2, и 4 — все они AUGraph* вызовы функции — были добавлены к графику “к - действительно” перечисляют. Вызвать AUGraphUpdate выполнить эти незаконченные задачи. По успешному возврату AUGraphUpdate функция, график был динамично реконфигурирован и iPod, EQ существует и аудио обработки.

Аудио потоки через график Используя «получение по запросу»

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

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

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

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

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

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

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

4. Функция обратного вызова рендеринга Вашего приложения является конечным получателем получения по запросу. Это предоставляет требуемые кадры к модулю эффекта.

5. Модуль эффекта обрабатывает часть, предоставленную обратным вызовом рендеринга Вашего приложения. Модуль эффекта тогда снабжает обработанными данными, которые ранее требовали (на шаге 2) к Удаленному модулю I/O.

6. Удаленный модуль I/O обрабатывает часть, предоставленную модулем эффекта. Удаленный модуль I/O тогда предоставляет обработанную часть, которую первоначально требуют (на шаге 1) к виртуальному устройству вывода. Это завершает один цикл получения по запросу.

Понимание функции обратного вызова рендеринга аудиоустройства

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

Перечисление 1-5  заголовок функции обратного вызова рендеринга

static OSStatus MyAURenderCallback (

    void                        *inRefCon,

    AudioUnitRenderActionFlags  *ioActionFlags,

    const AudioTimeStamp        *inTimeStamp,

    UInt32                      inBusNumber,

    UInt32                      inNumberFrames,

    AudioBufferList             *ioData

) { /* callback body */ }

inRefCon параметр указывает на программируемый контекст, который Вы указываете при присоединении обратного вызова к вводу аудиоустройства (см. Функции обратного вызова Рендеринга Записи и Присоединения). Цель этого контекста состоит в том, чтобы предоставить функции обратного вызова любые данные аудиовхода или информацию состояния, это должно вычислить выходное аудио для данного вызова рендеринга.

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

*ioActionFlags |= kAudioUnitRenderAction_OutputIsSilence;

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

inTimeStamp параметр представляет время, в которое был вызван обратный вызов. Это содержит AudioTimeStamp структура, mSampleTime поле которой является счетчиком демонстрационного кадра. На каждом вызове обратного вызова значение mSampleTime поля постепенно увеличивается числом в inNumberFrames параметре. Если Ваше приложение является секвенсером или драм-машиной, например, можно использовать значение mSampleTime для планирования звуков.

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

inNumberFrames параметр указывает число кадров аудиосэмпла, которые обратный вызов просят обеспечить на текущем вызове. Вы обеспечиваете те кадры для буферов в параметре йодата.

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

При игре тишины для определенного вызова обратного вызова явно установите эти буферы в 0, такой как при помощи memset функция.

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

Работа со структурой AudioStreamBasicDescription

Валюта для того, чтобы переместить аудио значения в Вашем приложении, и между Вашим приложением и аудио аппаратными средствами, AudioStreamBasicDescription структура, показанная в Перечислении 1-6 и, описала полностью в Ссылке Типов данных Core Audio.

Перечисление 1-6  AudioStreamBasicDescription структура

struct AudioStreamBasicDescription {

    Float64 mSampleRate;

    UInt32  mFormatID;

    UInt32  mFormatFlags;

    UInt32  mBytesPerPacket;

    UInt32  mFramesPerPacket;

    UInt32  mBytesPerFrame;

    UInt32  mChannelsPerFrame;

    UInt32  mBitsPerChannel;

    UInt32  mReserved;

};

typedef struct AudioStreamBasicDescription  AudioStreamBasicDescription;

Поскольку имя AudioStreamBasicDescription длинно, это часто сокращается в разговоре и документации как ASBD. Для определения значений для полей ASBD запишите код, подобный показанному в Перечислении 1-7.

Перечисление 1-7  , Определяющее ASBD для потока стерео

size_t bytesPerSample = sizeof (AudioUnitSampleType);

AudioStreamBasicDescription stereoStreamFormat = {0};

stereoStreamFormat.mFormatID          = kAudioFormatLinearPCM;

stereoStreamFormat.mFormatFlags       = kAudioFormatFlagsAudioUnitCanonical;

stereoStreamFormat.mBytesPerPacket    = bytesPerSample;

stereoStreamFormat.mBytesPerFrame     = bytesPerSample;

stereoStreamFormat.mFramesPerPacket   = 1;

stereoStreamFormat.mBitsPerChannel    = 8 * bytesPerSample;

stereoStreamFormat.mChannelsPerFrame  = 2;           // 2 indicates stereo

stereoStreamFormat.mSampleRate        = graphSampleRate;

Для запуска определите тип данных для представления одного значения аудиосэмпла. Этот пример использует AudioUnitSampleType определенный тип, рекомендуемый тип данных для большинства аудиоустройств. В iOS, AudioUnitSampleType определяется, чтобы быть 8,24 целыми числами фиксированной точки. Первая строка в Перечислении 1-7 вычисляет число байтов в типе; то число требуется при определении некоторых значений полей ASBD, как Вы видите в перечислении.

Затем, все еще обращаясь к Перечислению 1-7, объявите переменную типа AudioStreamBasicDescription и инициализируйте его поля к 0, чтобы гарантировать, чтобы никакие поля не содержали данные мусора. Не пропускайте этот шаг обнуления; если Вы делаете, Вы несомненно столкнетесь с проблемой позже.

Теперь определите значения полей ASBD. Указать kAudioFormatLinearPCM для mFormatID поля. Несжатые аудиоданные использования аудиоустройств, таким образом, это - идентификатор правильного формата для использования каждый раз, когда Вы работаете с аудиоустройствами.

Затем, для большинства аудиоустройств, укажите kAudioFormatFlagsAudioUnitCanonical метафлаг для mFormatFlags поля. Этот флаг определяется в CoreAudio.framework/CoreAudioTypes.h следующим образом:

kAudioFormatFlagsAudioUnitCanonical = kAudioFormatFlagIsFloat |

                                kAudioFormatFlagsNativeEndian |

                                     kAudioFormatFlagIsPacked |

                             kAudioFormatFlagIsNonInterleaved

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

Определенные аудиоустройства используют нетипичный формат аудиоданных, требуя различного типа данных для выборок и различного набора флагов для mFormatFlags поля. Например, 3D модуль Микшера требует UInt16 тип данных для его аудиосэмпла оценивает и требует, чтобы mFormatFlags поле ASBD было установлено в kAudioFormatFlagsCanonical. При работе с определенным аудиоустройством, стараться использовать корректный формат данных и флаги правильного формата. (См. Используя Определенные Аудиоустройства.)

Продолжаясь через Перечисление 1-7, следующие четыре поля далее указывают организацию и значение битов в демонстрационном кадре. Установите эти поля — mBytesPerPacket, mBytesPerFrame, mFramesPerPacket, и mBitsPerChannel поля — согласно природе аудиопотока, который Вы используете. Для изучения значения каждого из этих полей обратитесь к документации для AudioStreamBasicDescription структура. Вы видите пример заполненного ASBDs в проекте примера кода Аудио Микшер (MixerHost).

Установите mChannelsPerFrame поле ASBD согласно числу каналов в потоке — 1 для моно аудио, 2 для стерео, и т.д.

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

Вместо того, чтобы указывать поле ASBD полем, как Вы видели здесь, можно использовать служебные методы C++, предоставленные в CAStreamBasicDescription.h файл (/Developer/Extras/CoreAudio/PublicUtility/). В частности просмотрите SetAUCanonical и SetCanonical Методы C++. Они указывают корректный способ получить значения полей ASBD, данные три фактора:

• Является ли поток для I/O (SetCanonical) или для обработки аудиоданных (SetAUCanonical)

• Сколько каналов Вы хотите, чтобы потоковый формат представлял

• Хотите ли Вы потоковый формат, чередованный или нечередующийся

Включаете ли Вы CAStreamBasicDescription.h файл в Вашем проекте использовать его методы непосредственно, Apple рекомендует изучить тот файл для изучения корректного способа работать с AudioStreamBasicDescription структура.

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

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

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

Аудиовход и выходные аппаратные средства на устройстве на iOS определили системой форматы аудиопотока. Эти форматы являются всегда несжатыми, в линейном формате PCM, и чередуются. Система налагает эти форматы на обращающиеся исходящим образом стороны модуля I/O в графике обработки аудиоданных, как изображено на рисунке 1-8.

В числе микрофон представляет входные аппаратные средства аудио. Система решает, что входной аудиопоток аппаратных средств форматирует, и налагает его на входной объем Удаленного входного элемента модуля I/O.

Точно так же громкоговорители в числе представляют выходные аппаратные средства аудио. Система решает, что выходной поток аппаратных средств форматирует, и налагает его на выходной объем Удаленного выходного элемента модуля I/O.

Ваше приложение ответственно за установление форматов аудиопотока на внутрь обращающихся сторонах элементов модуля I/O. Модуль I/O выполняет любое необходимое преобразование между Вашими форматами приложения и аппаратными форматами. Ваше приложение также ответственно за установку потоковых форматов везде, где еще они требуются в графике. В некоторых случаях, такой как при выводе Многоканального модуля Микшера на рисунке 1-8, необходимо установить только часть формата — в частности, частота дискретизации. Запустите путем Выбора Design Pattern, показывает Вам, где установить потоковые форматы для различных типов приложений аудиоустройства. Используя Определенные Аудиоустройства перечисляет потоковые требования формата для каждого аудиоустройства iOS.

Главная особенность соединения аудиоустройства, как показано на рисунке 1-8, то, что соединение распространяет формат потока аудиоданных от вывода его исходного аудиоустройства к вводу его целевого аудиоустройства. Это - критическая точка, таким образом, она переносит подчеркивание: Потоковое распространение формата имеет место посредством соединения аудиоустройства и в одном направлении только — от вывода исходного аудиоустройства к вводу целевого аудиоустройства.

Используйте в своих интересах распространение формата. Это может значительно сократить объем кода, который необходимо записать. Например, при соединении вывода Многоканального модуля Микшера к Удаленному модулю I/O для воспроизведения, Вы не должны устанавливать потоковый формат для модуля I/O. Это установлено соответственно соединением между аудиоустройствами, на основе формата потока вывода микшера (см. рисунок 1-8).

Потоковое распространение формата имеет место в одной определенной точке в жизненном цикле графика обработки аудиоданных — а именно, на инициализацию. Посмотрите Инициализируют и Запускают График Обработки аудиоданных.

У Вас есть большая гибкость в определении Ваших форматов аудиопотока приложения. Однако, когда это возможно, используйте частоту дискретизации, которую используют аппаратные средства. Когда Вы делаете, модуль I/O не должен выполнять преобразование частоты дискретизации. Это минимизирует энергетическое использование — важное рассмотрение в мобильном устройстве — и максимизирует качество звука. Для приобретения знаний о работе с аппаратной частотой дискретизации посмотрите, Конфигурируют Аудио Сеанс.