Проектирование и разработка подсистемы виртуализации звука в Parallels Desktop (1187416)
Текст из файла
Министерство образования и науки Российской Федерации
Федеральное государственное автономное образовательное учреждение высшего профессионального образования
«Московский физико-технический институт
(государственный университет)»
Факультет управления и прикладной математики
Кафедра теоретической и прикладной информатики
Проектирование и разработка подсистемы виртуализации звука в Parallels Desktop
Выпускная квалификационная работа
(магистерская диссертация)
Направление подготовки: 03.04.01 Прикладная математика и физика
Выполнил:
студент 973 группы Бондарь Артем Олегович
Научный руководитель:
д. ф.-м.н, профессор Тормасов Александр Геннадьевич
Научный консультант:
Преподаватель Мелехова Анна Леонидовна
Москва 2015
Оглавление
1.2 Виртуализация мультимедиа 5
1.3 Системы реального времени 6
1.3 Проблемы виртуализации средств поддержки мультимедиа 11
2. Постановка задачи 16
3. Обзор существующих решений работы со звуком 19
3.1 Архитектурные подходы к виртуализации аудио потока 19
3.2 Существующие аудио библиотеки 21
3.2.1 Portaudio 22
3.2.2 RTAudio 23
3.2.3 JUCE 24
3.2.4 Core Audio 25
3.3 Заключение 27
4. Ход работ 28
4.1. Сравнительный анализ архитектурных подходов по виртуализации аудио устройств 28
4.1.1 Формальная модель аудио потока 28
4.1.2 Оценка мультипликативной константы модели 31
4.1.3 Интерпретация модели как Марковской цепи 33
4.1.4 Оценка метрики, характеризующей качество аудио потока 34
4.1.5 Сравнение архитектурных подходов в рамках приведенной формализации 36
4.2 Архитектура потоковой виртуализации аудио данных 39
4.3 Разработка аудио библиотеки 41
5. Оценка результатов работы 44
6. Заключение 45
7. Список использованной литературы 47
1. Введение в проблематику
1.1 Виртуализационные технологии.
Парадигма облачных вычислений в последние годы обрела высокую популярность в индустрии информационных технологий, что, в свою очередь, поспособствовало все более бурному развитию технологий аппаратной виртуализации [1]. Эта технология позволяет одновременно исполняться нескольким операционным системам в рамках одной физической машины. Такой сценарий работы системы реализуется посредством изоляции операционных систем от реального оборудования при помощи дополнительного программного слоя абстракции - гипервизора [2, 3]. Его задача - эмулировать поведение реальных устройств таким образом, что бы операционные системы могли работать так же, как если бы они имели эксклюзивный доступ к оборудованию.
Существующие конфигурации виртуализированных систем могут быть разделены на два широких класса: гипервизоры работающие без использования сервисной (хостовой) ОС и гипервизоры использующие сервисную ОС (гипервизоры первого и второго типа [38]). Гипервизоры первого типа по сути являются микро-ОС, так как сами могут работать с оборудованием, обслуживая запросы изолированных ОС (гостевые ОС). Примером такого гипервизороа являются VMWare ESXi [4]. Гипервизоры же второго типа не содержат в себе драйверов для работы с аппаратурой и исполняются как сервис хостовой ОС, которая и обслуживает все запросы по работе с оборудованием, приходящие от гостевых ОС. Такой метод виртуализации реализован в проектах KVM [5], VMWare Workstation [6], Parallels Desktop [7]. В рамках этой работы мы остановим свое внимание на гипервизорах второго типа.
Виртуализированные системы имеют ряд свойств, обеспечивших высокую популярность решений по аппаратной виртуализации в IT индустрии [39]. Среди них особенно стоит выделить высокий уровень утилизации ресурсов, надежность и гибкость в управления системой. Действительно, виртуальные машины изолированы друг от друга гипервизором и в любой момент могут быть скопированы или перемещены между реальными машинами, в том числе и без остановки (технология живой миграции [8]). Это позволяет реализовывать множество сценариев, повышающих надежность системы и ее эффективность.
Но при этом необходимо понимать, что виртуализационное ПО должно эффективно эмулировать очень широкий спектр аппаратуры, что подчас требует от виртуальной машины работы с учетом ряда ограничений, вызванных спецификой работы физических устройств. Одной из областей, в которой подобная специфика вносит ряд серьезных затруднений при написании виртуализационного ПО, это виртуализация средств мультимедиа.
1.2 Виртуализация мультимедиа
Вопросы виртуализации устройств мультимедиа и в частности аудио устройств приобрели особенную актуальность с развитием разработок виртуальных машин, рассчитанных для использования на рынке десктопной виртуализации (продукты вроде Virtual Box, Parallels Desktop и VMWare Workstation). В этом случае основной целью использования виртуальной машины является запуск приложений, не совместимых с используемой ОС. Таким приложением может являться приложение по работе с мультимедиа, и в коммерческом виртуализационном решении качество эмуляции мультимедиа устройств имеет большое значение.
В то же время цифровая аудио система имеет жесткие временные ограничения: если мы опаздаем с генерацией фрагмента аудио данных, то аудиопоток будет прерван и пользователь услышит искажения сигнала. Иными словами аудио система является системой реального времени, то есть она должна гарантировать выполнения вычислений с задержкой, не превышающей заданную. Имплементация таких систем сопряжена с рядом трудностей даже в рамках невиртуализированной среды, и тем более является проблемной в случае использования технологий виртуализации. В следующих главах мы рассмотрим причины этих затруднений и рассмотрим особенности написания таких систем.
1.3 Системы реального времени
Рассмотрим некоторую вычислительную систему, задачей которой является исполнение некоторой процедуры в ответ на внешнее событие. Если результат этих вычислений актуален и ценен только в течении определенного интервала времени с момента получения события (deadline), то такая система называется системой реального времени [9]. Разделяют такие системы на два подтипа:
- Система мягкого реального времени - система в которой ответ тем менее актуален, чем дольше он запоздал к deadline.
- Система жесткого реального времени - система в котором ответ теряет актуальность полностью после опоздания к deadline.
Примерами систем жесткого реального времени являются цифровые контроллеры в двигателе автомобиля, где запаздывание ответа может привести к автокатастрофе.
К системам мягкого реального времени причисляют большинство цифровых бытовых мультимедиа систем, в частности аудио и видео системы, в которых запаздывания приводят к искажению воспроизводимого сигнала, которые легко улавливаются человеческими органами восприятия.
Проблемы разработки систем жесткого реального времени мы оставим в рамках этой работы без должного внимания, в связи с тем, что это большая область, не имеющая прямого отношения к вопросам, поставленным в этой работе, и сконцентруемся на вопросах написания систем мягкого реального времени.
Написание систем мягкого реального времени является хорошо изученной областью, и современные ОС умеют давать гарантии исполнения пользовательского кода с указанными ограничениями в случае выполнения следующих правил [13]:
- Код, чувствительный к задержкам, должен исполняться в системе с максимальным приоритетом
- Запрещено использовать системные вызовы, потенциально блокирующие исполнение (такие как обращения к файловой системе и сети, выделение/освобождение памяти)
- Запрещено использовать блокирующие примитивы синхронизации. Исключением является использование вызовов типа trylock(), исполняющихся за ограниченное сверху время
Как уже было указано выше, аудио система ОС является системой реального времени. Такая классификация применима в связи с тем, что в случае, если генератор аудио потока не успеет сгенерировать пакет данных к моменту, когда те должны будут начать воспроизводиться, то аудио контроллер вынужден будет остановить воспроизведение звука на некоторый промежуток времени, равный времени запаздывания, что будет звучать для слушателя как щелчок. В случае нескольких таких опазданий, разделенных короткими промежутками времени звук будет сильно искажен лишним шумом, природа которого заключается в резком изменении спектральной картины на границах выпадений аудио данных цифрового потока. Широкое использование персональных компьютеров в музыкальной индустрии приводит к тому, что они часто оказываются подключенными к усиливающей аппаратуре, для которой такие резкие звуковые скачки могут быть нежелательны, а иногда и опасны. В случае же записи выпадение данных приводит к искаженному записанному сигналу, что в случае профессионального использования неприемлемо.
Принимая во внимание правила написание кода реального времени исполнения, мы можем построить концептуальную схему работы аудио системы (Рис 1):
- Для аудио генератора выделяется необходимая память, загружаются все необходимые ресурсы с жесткого диска, или из сети, либо инициируется процесс асинхронной подкачки данных в буфер.
- Далее запускается процесс воспроизведения: аудио контроллер периодически запрашивает у звукового модуля данные (как правило при помощи функции обратного вызова) и аудио модуль либо генерирует их, либо берет уже подгруженные в память данные (если они уже успели загрузиться), либо оповещает звуковой контроллер об отсутствии аудио данных.
Рис 1. Архитектура аудиопотока (output) в современных ОС
Для входящего потока аудио данных (input) работают та же схема, но меняется направление движения аудио данных.
Как видно из описания, следование правилам написания системы мягкого реального времени не может дать полной гарантии непрерывности звукового потока в операционных системах с многозадачностью (каковыми являются большинство современных ОС). И тем не менее такой подход обеспечивает приемлемое качество звука - это становится возможным благодаря продуманным политикам выставления задержки (latency) в воспроизведении аудио потока.
Задержка между началом генерации аудио данных и стартом их воспроизведения (либо между началом записи звука и началом приема аудио данных записывающим приложением), так же называемая пребуферизацией, - это основной инструмент снижения рисков нарушения непрерывности аудио потока в современных операционных системах [14, 15, 16]. И это кажется вполне естественным - чем выше задержка, тем больше готовых для воспроизведения данных буферизировано, а значит в случае, если генератор по каким-либо причинам нарушит расписание синтеза новых данных, то у него будет возможность наверстать упущенное, пока аудио подсистема проигрывает/обрабатывает уже готовые для этого данные (более подробно этот вопрос будет рассмотрен в разделе 4.1). С другой стороны, задержки в воспроизведении звука свыше 180 мс в случае воспроизведения мультимедиа [17] и 400 мс для VoIP систем [18] уже различимы человеком и неприемлемы. Для систем работающих с цифровой обработкой звука этот параметр еще ниже: при задержках в 2-5 мс тембральная картина меняется, а при превышении порога в 10 мс эта задержка становится явно различимой, и не позволяет качественно работать с полученным аудио сигналом [19]. Для достижения высокого качества работы аудио системы разработчики операционных систем стараются выдерживать баланс между стабильностью аудио потока и величиной задержки. Для современных операционных систем характерны следующие минимальные величины задержки [14]:
- OSX - 2мс
- Windows - зависит от реализации драйвера (8 - 400мс). При использовании драйверов ASIO [20] - снижена до 1 - 2мс
- Unix-до10мс
Но при этом очень важно понимать, что до этого момента мы рассматривали задержку между началом генерации данных и стартом их воспроизведения (так же известную как величина пребуферизации), тогда как общая величина задержки в системе включает в себя еще и составляющую, связанную с не мгновенностью передачи контрольных сообщений (далее по тексту - нежелательная задержка). Природа этой составляющей заключается в том, что контрольные сигналы как правило даются пользователем системы через устройства ввода/вывода, обработка которых ведется с гораздо более низким приоритетом и меньшим вниманием к скорости отзывчивости. Эта часть задержки может давать существенный вклад в общую величину, при этом, по понятным причинам, она не влияет на стабильность воспроизведения аудиоданных.
Таким образом популярные операционные системы позволяют работать со звуком в режиме мягкого реального времени благодаря нескольким основным факторам:
- Код аудио рендеринга/обработки исполняется с наивысшим приоритетом
- Аудио подсистемы написаны с соблюдением правил написания кода мягкого реального времени исполнения
- Использованы максимально эффективные алгоритмы и методы работы с потоком аудио данных для снижения нежелательной составляющей задержки
- В системе выставляется максимальная задержка в рамках приемлемых значений
1.3 Проблемы виртуализации средств поддержки мультимедиа
Теперь же рассмотрим случай виртуализированой системы на базе гипервизора второго типа. В такой конфигурации гостевая и хостовая операционные системы изолированы друг от друга гипервизором, и виртуальная машина делегирует работу гостевой ОС c оборудованием хостовой ОС. Не вдаваясь в детали реализации, общую архитектуру виртуальной машины, опирающейся на технологию аппаратной виртуализации на платформе x86 можно описать следующим образом [35] (рис 2):
Рис 2. Архитектура виртуальной машины, опирающейся на средства аппаратной виртуализации
Характеристики
Тип файла документ
Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.
Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.
Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
