Проектирование и разработка подсистемы виртуализации звука в Parallels Desktop (1187416), страница 2
Текст из файла (страница 2)
- Виртуальная машина – это пользовательский процесс в хостовой операционной системе, который выделяет под нужды гостевой операционной системы память, и передает управление коду монитора виртуальных машин
- Монитор виртуальных машин сохраняет контекст операционной системы и переходит в собственный контекст исполнения, изолированный от хостового. В нем монитор виртуальных машин переводит процессор в режим поддержки виртуализации и передает исполнение гостевому коду. В случае, если гостевой код выполняет обращение к аппаратуре, то такой запрос перехватывается, и исполнение возвращается монитору виртуальных машин. Если этот запрос требует обращения к реальному оборудованию, то он передается в пользовательский процесс, который исполняет его.
При такой архитектуре указанные выше проблемы существующих имплементаций аудио подсистемы в современных ОС существенно усугубляются следующими факторами:
- Гостевая ОС отдает аудио данные не напрямую в оборудование, а в буфер виртуальной машины (эмулированный DMA буфер), из которой их забирает для воспроизведения хостовая ОС (либо же гостевая ОС получает буферизированные данные, которые должны быть еще сгенерированы на хосте для случая записи звука). Это означает, что нежелательная составляющая задержки аудио потока складывается как минимум из задержки хостовой и гостевой ОС.
- Виртуальная машина исполняется с приоритетом ниже, чем real-time, и поэтому в случае высокой загрузки хостовой ОС планировщик может не давать времени на исполнение виртуальной машине в течение произвольно долгого количества времени.
- Код эмуляции наиболее популярных виртуальных машин (KVM, XEN, Parallels Desktop, косвенно VMWare ESX, Microsoft HyperV), написан с нарушениями требований к написанию кода реального времени исполнения, и поэтому процедуры эмуляции могут исполняться произвольное долгое время (например в процессе выделения памяти, либо взятия блокировок). А это означает, что даже код гостевой ОС, удовлетворяющий требованиям написания кода реального времени исполнения, теряет описанные гарантии из за того, что время исполнения кода эмуляции не ограниченно сверху.
Из-за перечисленных проблем виртулизированный аудио тракт не может давать даже гарантий исполнения мягкого реального времени. Более того, этот результат невозможно улучшить без серьезной модификации эмуляционного кода существующих виртуальных машин, так как те грубо нарушают правила написания систем реального времени. Однако виртуальная машина реального времени исполнения имеет и свои слабые стороны: сложность такой системы заметно возрастет, а ограничение времени исполнения эмуляционных операций приведет к деградации производительности. Поэтому в коммерческих продуктах такой подход является чрезмерным. Из инструментов борьбы за качество мультимедиа в виртуализированной среде у разработчиков виртуальных машин остаются только следующие:
- Управление приоритетами исполнения виртуальной машины
- Управление задержкой аудио тракта
- Использование максимально эффективных алгоритмов и подходов к написанию аудио тракта.
Среди перечисленных методов наименее популярным является подход, связанный с управлением приоритета потоков. Это связано с тем что такое управление часто требует серьезных архитектурных изменений и наталкивается на трудноразрешимые проблемы приоритезации, вроде инверсии приоритетов. Поэтому в коммерческих продуктах такой подход применяется редко, и встретить его можно лишь в виде академических разработок на базе Xen [10,12].
В свою очередь управление задержкой, как наиболее предсказуемый подход, применяется довольно часто в таких проектах как KVM-Qemu (по умолчанию выставлена задержка в 10мс [21]), Virtual Box (по умолчанию - 20 мс [22]). В продукте Parallels Desktop задержка выставляется в зависимости от типа хостовой ОС и составляет 20 миллисекунд для OSX и 50 для Windows/linux.
Помимо этого немалый вклад в надежность аудио системы дает продуманный выбор архитектурных решений и алгоритмов, так как в виртуализированной среде модель потока данных в сравнении с той, что реализована в операционных системах, работающих без средств виртуализации, является более сложной. В потоке данных появляется новый узел, ответственный за обработку и передачу данных.
Рис 3. Архитектура виртуализированного аудио потока
На рисунке 3 изображения схема работы виртуализированного аудио
потока. На этой схеме все вызовы являются синхронными, но процессы внутри кода эмуляции могут быть асинхронными, более того подход к передаче данных сильно различается в различных виртуальных машинах и это связано с особенностью работы DMA буфера аудио контроллера.
Этот буфер реализован как кольцевой буфер, и драйвер аудио карты следит за количеством проигранных данных, наблюдая за значением первого из указателей буфера. Это означает, что гостевая операционная система начнет генерировать новый квант данных только если указатель был смещен (данные воспроизведены с точки зрения гостя). Но при этом после перемещения указателя с начала кванта данных на его конец делает эти данные невалидными для компонентов виртуальной машины, так как после перемещения указателя гостевая ОС считает эту часть буфера уже проигранной аудио устройством, а значит свободной для новой записи. С учетом вышесказанного, логика работы эмулированного DMA буфера может быть реализована несколькими способами – обзор этих подходов дан в главе 3.1, а анализ их преимуществ и недостатков дан в главе 4.1.
2. Постановка задачи
В рамках данной работы мы рассмотри виртуальную машину Parallels Desktop. В силу специфики приложения в качестве хостовой ОС мы будем рассматривать только систему OS X. Аудио подсистема эмулирует AC’97- совместимую аудио карточку [24]. Текущая архитектура воплощает следующие решения:
1. В качестве хостового аудио компонента используется библиотека PortAudio [25]
2. Передача данных из DMA буфера в аудио модуль хостовой ОС организована опосредованно при помощи кольцевого буфера
3. Доступ к контрольным регистрам аудио карточки обрабатывается частью приложения, работающей в пользователськом режиме, тогда как монитор виртуальной машины работает в режиме проброса запросов.
Для описанной конфигурации в течении нескольких лет эксплуатации были выявлены следующие проблемы:
- Высокая нежелательная задержка вносимая хостовым аудио компонентом
- Низкая производительность аудио подсистемы при изменении параметров эмулируемого аппаратного микшера аудио карты. Связано с тем, что любой запрос на изменение (например автоматическая подстройка громкости звука в реальном времени) вызывает длительный процесс доступа из монитора виртуальных машин к пользовательскому приложению. Особенно критично эта проблема проявлялась в случае использования VoIP приложений, автоматически подстраивающих громкость микрофона в процессе работы.
- Проблемы перечисления присутствующих в системе аудио устройств, связанной с особенностями реализации библиотеки PortAudio.
- Жесткая привязка кода эмуляции в пользовательском приложении к спецификации AC’97.
- Невозможность использования системных преобразователей форматов, предоставляемых Core Audio в OS X в библиотеке PortAudio в случае если устройство не поддерживает формат, запрашиваемый гостевой ОС.
Описанные проблемы являются очевидным следствием принятых архитектурных решений (1-е и 3-е), и их разрешение требует отказа от описанных подходов и серьезной переработки аудио стека, и в этом смысле кажется абсолютно естественным оценить и уместность 2-го архитектурного решения, что бы в случае если описанный подход окажется неудачным и в дальнейшем станет новой ключевой проблемой, то в будущем не было бы необходимости очередного пересмотра архитектуры.
Таким образом, в рамках данной работы мы ставим себе цель улучшить характеристики аудио подсистемы продукта Parallels Desktop, последовательно выполнив следующие подзадачи:
- Анализ и выбор наиболее эффективного подхода к трансферу аудио данных между эмулированным DMA буфером и хостовой аудио подсистемой.
- Анализ существующих аудио библиотек и выбор наиболее подходящей вместо PortAudio.
- Проектирование новой архитектуры на базе принятых решений (новая библиотека, подход к эмуляции, перенос AC’97 логики в монитор виртуальных машин)
При этом необходимо учитывать тот факт, что в аудио системе стабильность воспроизведения является необходимым условием – т.е. уменьшение задержки не должно достигаться за счет ухудшения стабильности аудио подсистемы. В главе 3.1 дан обзор двух основных подходов к виртуализации аудио карты – их детальный анализ приведен в 4.1. В главе 3.2 дан обзор существующих библиотек реализующих поддержку мультимедиа, а в главах 4.2-4.3 описана имплементация аудио подсистемы на базе выбранных решений.
3. Обзор существующих решений работы со звуком
3.1 Архитектурные подходы к виртуализации аудио потока
Основная проблема при организации потока аудио данных из гостевой системы заключается в том, что подсистемы работают в разных режимах: гостевая работает в режиме push, тогда как хостовая в режиме pull [26]. Поэтому встает вопрос в том, каким образом связать эти два потока данных с учетом необходимости поддержания синхронности скорости генерации и потребления данных.
Рис 3. Схема работы аудио потока в случае воспроизведения данных из виртуальной машины
Решать данную проблему можно при помощи двух различных подходов:
- Запрос на трансфер данных между хостовой аудио системой и виртуальной машиной происходит по требованию хостовой системы. При этом данные при записи берутся напрямую из DMA, и гостевая система оповещается о том, что они проиграны только когда хостовая система запросит новый квант данных. Соответственно в случае записи звука запись идет напрямую в буфер. Такой подход реализован в проекте QEMU.
- Между DMA регионом виртуальной машины и хостовой аудио системой устанавливается дополнительный single-consumer-single- producer буфер, через который осуществляется передача данных. В таком случае виртуальная машина и хостовая аудио подсистема работают в асинхронном режиме. Такой подход использован в Virtual Box и текущей версии Parallels Desktop.
Среди очевидных преимуществ первого подхода можно выделить то, что нет двух дополнительных трансферов данных, но в то же время можно заметить, что в этом случае мы лишаемся преимуществ асинхронной работы (а именно возможностью более гибкой работы с задержкой аудио потока). Поэтому делать окончательный вывод о преимуществе одного подхода над другим можно только на базе более детального исследования, ход которого и результаты будут представлены в главе 4.1.
3.2 Существующие аудио библиотеки
В предыдущей главе мы рассмотрели различные подходы к виртуализации звука в предположении, что генерация аудиоданных и их передача в звуковое устройство происходит без существенных временных затрат, связанных с процессингом аудио (преобразование форматов, применение громкости, и т. д.). На практике же библиотеки, предоставляющие доступ к аудио оборудованию, оптимизируя свое поведения под конкретные паттерны использования, подчас жертвуя производительностью при других подходах к использованию. Поэтому выбор подходящей аудио библиотеки позволит улучшить характеристики аудио подсистемы.
Среди требований к аудио библиотеке особенно стоит выделить следующие:
1. Поддержка non-interleaved форматов PCM8, PCM16, PCM24, PCM32.
2. Поддержка преобразования частоты дискретизации и микширования каналов
3. Отсутствие связывания каналов воспроизведения и записи
4. Низкая дополнительная задержка, вносимая в аудио тракт.
5. Библиотека должна работать на операционной системе OSX
Пункт 3 требует пояснений: некоторые аудио библиотеки были изначально написаны для процессинга аудио-данных в формате реального времени, что накладывает ряд архитектурных ограничений на процесс функционирования аудио системы. В нашем случае устройства воспроизведения и записи являются отдельными устройствами, и процесс передачи данных по этим каналам не должен быть синхронизирован, тогда как процессинг данных в реальном времени предполагает связывание этих двух потоков одной функцией обратного вызова, которая дает данные на обработку и ждет в ответ обработанных данных.
Таким образом, имея ряд требований к аудио библиотеке, мы можем сделать обзор на наиболее популярные и принять решение о целесообразности использования одной из них.
3.2.1 Portaudio
Библиотека Portaudio[24] использовалась в для работы с аудио в проекте Parallels Desktop. Основным ее преимуществом являлась кроссплатформенность. Это было важным свойством, так как до недавнего времени кодовая база этой виртуальной машины использовалась для нескольких продуктов – в том числе и для Parallels Workstation, которая работала на ОС Windows и Linux. Но в то же время в процессе использования было выявлено довольно большое количество проблем, среди которых выделяются следующие:
- Библиотека предназначена в первую очередь для обработки аудио данных в реальном времени – это означает, что библиотека в одной функции обратного вызова как передает буфер с данными со входа, так и требует заполнить буфер с данными на выход. Это означает, что виртуальное устройство записи и виртуальное устройство воспроизведения приходится синхронизировать на уровне доступа к аудио библиотеки. Такое поведение вызывает ряд проблеем: начиная от невозможности выставления различных задержек этим двум потокам, заканчивая необходимостью синхронизации контрольных вызовов.
- Нестабильность библиотеки при многократном открытии/закрытии аудио устройств. Такое поведение было критически необходимо, так как в ОС Windows открытие аудио устройства приводило к удержанию в рабочем состоянии мультимедийного таймера, что снижало время жизни работы от батареи. В OSX же многократное открытие/закрытие устройств приводило к проблемам с выставлением аудио формата, при котором аудио устройство начинало неверно интерпретировать цифровые аудио данные.
- Изменение идентификаторов аудио устройств после ре-инициализации библиотеки. Как было уже указано – в процессе работы приложения приходится довольно часто ре-инициализировать библиотеку Portaudio, но при этом она не гарантирует неизменность идентификаторов аудио устройств, что приводило к необходимости использования решений, усложняющих архитектуру.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
