Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Таким образом как только было принято решение отказаться от поддержки ОС Windows и Linux в Parallels Desktop, возникла возможность перейти на более подходящую аудио библиотеку.

Более того: при внимательном анализе кода движка веб браузеров Chromium [28] обнаруживается, что архитектурные решения и код работы с аудио был частично взят из Portaudio, но со временем от этого кода все сильнее отказывались, пока аудио компонент не был окончательно переписан.

3.2.2 RTAudio

RTAudio [29] – популярная кроссплатформенная C++ аудио библиотека, предоставляющая простой API для работы с аудио оборудованием. Причиной интереса к этой библиотеки являлось то, что в отличии от других эта библиотека не предполагала работу в дуплексном режиме как основной подход, что означало что функции обратного вызова для устройств записи и воспроизведения не синхронизированы. Согласно документации, библиотека предоставляла все инструменты, необходимые для работы виртуализационного ПО, в том числе и:

- Поддержка динамической смены устройств

- Поддержка различных форматов, в том числе и non-interleaved signed integer (необходимое условие поддержки PCM)

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

Но в то же время анализ исходного показал, что использование этой

библиотеки представляется невозможным в связи со следующими проблемами:

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

- Библиотека не позволяет выставить битрейт – предоставляется возможность использования только 32-битного потока

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

3.2.3 JUCE

JUCE [30] – кросплатформенный фреймворк, предоставляющий широкий инструментарий, включающий в себя модули работы с двухмерной графикой, звуком, интерфейсом пользователя и рядом других возможностей. Этот фреймворк часто используется для создания виртуальных инструментов в формате VST [31], для которых высокая производительность обработки и передачи аудиоданных является критически важным свойством. Именно поэтому JUCE был выбран в качестве возможного решения. Среди плюсов этой библиотеки необходимо выделить:

- Высокое внимание разработчиков к вопросам производительности аудио стека.

- Поддержка необходимых форматов задекларирована в документации.

Но в то же время детальный анализ выявил следующие проблемы:

- Как и в библиотеке RTAudio поддержка различных частот

дискретизации работала только в случае поддержки этих частот аудио устройством – встроенная конвертация отсутствовала

- Бедные возможности управления устройствами – нет функционала подписки на изменения в списке аудио устройств

- Отсутствие поддержки PCM форматов.

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

3.2.4 Core Audio

Core Audio [31] – это компонент операционной системы OS X, предоставляющий низкоуровневый интерфейс для работы с аудио устройствами на языке C. Фактически перечисленные выше фреймворки реализуют свой функционал для операционной системе OS X, используя Core Audio. Особенностью этой библиотеки является возможность тонкой настройки параметров аудио тракта и широкий набор средств по обработке форматов аудио данных. Фактически, все требования выставленные к аудио компоненту, согласно документации, могут быть удовлетворены средствами Core Audio. Главным минусом такого подхода является необходимость написания полноценного компонента, отвечающего за работу с аудио оборудованием, и предоставляющего высокоуровневый интерфейс эмуляционному коду. Но как показал анализ существующих решений – их расширение по трудоемкости сопоставимо, а иногда и превосходит по сложности написание своего фреймворка, в то время как создание своего аудио компонента позволит более эффективно использовать особенности архитектуры виртуализированного аудио тракта и добиться большего качества аудио в продукте Parallels Desktop.

3.3 Заключение

Анализ существующих решений в области поддержки аудио и виртуализации звука привели к следующим выводам:

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

- Необходимо провести детальное исследование двух подходов к виртуализации аудио потока, так как умозрительно сложно оценить преимущество одного над другим.

Ход описанных работ, а так же детали конечной реализации нового аудио стека в продукте Parallels Desktop даны в главе 4.

4. Ход работ

4.1. Сравнительный анализ архитектурных подходов по виртуализации аудио устройств

4.1.1 Формальная модель аудио потока

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

Рис 5. Формальная модель аудио системы

Здесь:

- количество буферезированных аудио данных (с)

– скорость генерации аудиоданных (с/с)

– количество воспроизведенных аудиоданных (с/с)

Введем динамическое уравнение, связывающее эти величины:

Для дальнейшего рассмотрения без доказательства примем следущие гипотезы:

- Передвижение данных между буфером и аудио устройством происходит мгновенно ( ). Этот эта предпосылка основана на экспериментальных данных: передача одного кванта аудио при характерном времени мс по продолжительности не превышает мкс. Таким образом:

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

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

- В случае, если количество буферизированных данных превышает , генератор не создаёт новых данных

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

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

Учитывая описанную выше логику можно смоделировать изменения значения величины следующим образом:

(4)

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

4.1.2 Оценка мультипликативной константы модели

Для оценки величины мы в среде OSX напишем простейшее аудио приложение, которое воспроизводит синусоидальный сигнал при помощи библиотеки Core Audio. Эта библиотека зовет функцию обратного вызова в пользовательском коде, которая должна генерировать аудио данные. При одним из аргументов в этом вызове является структура, позволяющая оценить состояние аудио потока. Используя эти данные, мы можем оценить изменение величины , измеренное через равные интервалы времени мс. Запустим тестовый стенд в агрессивном окружении –на операционной системе одновременно с нашим приложением будет работать несколько процессов, активно потребляющих CPU, имея при этом высокий приоритет исполнения. На рисунке 6 представлен один из графиков изменений величины , с течением времени на одном из запусков.

Рис 6. График функции . Обе величины измерены в миллисекундах

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

Характеристики

Список файлов ВКР