Проектирование и разработка подсистемы виртуализации звука в Parallels Desktop (1187416), страница 4

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

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

Рис 7. Гистограмма распределения неотрицательных значений

В приведенной гистограмме особенно выделяются два значения: 0 и 1. И опираясь на описанную модель эти два пика приобретают очевидную интерпретацию – пик в нуле соответствует стабильному режиму работы, когда количество произведенных данных на каждом шаге соответствует количеству проигранных данных за этот квант времени, в то время как пик в единице соответствует режиму ускоренной генерации аудиоданных. Таким образом случае форсированного режима:

А величина принимает вид:

4.1.3 Интерпретация модели как Марковской цепи

Учитывая полученные результаты мы можем перейти к следущей интерпретации нашей модели: можно представить как Марковский процесс с набором состояний: [0, , , … ] и матрицей переходов:

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

4.1.4 Оценка метрики, характеризующей качество аудио потока

Оценим вероятность того, что на шаге система окажется в состоянии 0, если в начальный момент времени она была в состоянии . Для этого рассмотрим произвольный путь, по которому система может попасть из состояния в состояние 0 за шагов. Обозначим каждый шаг в этом пути , где -1 сопоставлен переходу системы в состояние с более низким значением, 0 – значение шага, если система осталась в том же состоянии, и +1 сопоставлен переходу с большем значением. Докажем утверждение:

Утверждение 1. Вероятность осуществления траектории переходов системы равна

(5)

где - количество шагов , - количество шагов , - количество шагов проведенных в состоянии , - количество шагов проведенных в состоянии , - количество шагов проведенных в состоянии .

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

и докажем, что для каждой из таких последовательностей вероятность исполнения может быть представлена в виде (5) с использованием метода математической индукции:

Базис индукции:

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

Шаг индукции:

Пусть для последовательности шагов вероятность ее представлена в виде (5). Используя свойство независимости Марковской цепи рассчитаем вероятность выполнения последовательности :

Таким образом при любом значении и выражение соответствует виду (5). Утверждение доказано для в том числе и для N.

Утверждение 2. Вероятность осуществления траектории переходов системы из состояния в состояние 0 равна:

где

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

Таким образом искомую вероятность можно рассчитать как:

Имея аналитический вид вероятности попадание системы в состояние 0 мы находим инструмент управления рисками аудиотракта: учитывая то, что увеличивая значение мы уменьшаем вероятность попадания системы в нулевое состояние на произвольном шаге N.

4.1.5 Сравнение архитектурных подходов в рамках приведенной формализации

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

Для этого будем считать что в новой системе генератором аудио данных является виртуализационное ПО, и при этом задержка в воспроизведении во втором случае (когда между DMA буфером гостевой система и DMA буфером хостовой системы установлен дополнительный буфер) учетом двойной буферизации может быть рассчитана как:

В первом же случае (данные напрямую передаются из гостевого DMA буффера в хостовый), задержка в воспроизведении с точки зрения нашей модели соответствует величине . Является очевидным следующее утверждение: в случае 2-го подхода к виртуализации звука мы имеем полноценную возможность управлять значением величины , изменяя значнеие , тогда как 1-й подход лишен такой возможности.

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

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

- Во втором случае аудио подсистема будет реализована по втором сценарию – с использованием промежуточного аудио буфера. Но при этом глубина пребуферизации для него будет выставлена в 0, для того, что бы исключить его потенциальное влияние на значения и .

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

Таблица 1. Оценка значений и для разных подходов к виртуализации аудио подсистемы

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

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

4.2 Архитектура потоковой виртуализации аудио данных

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

- Неблокирующего кольцевого буфера [33]

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

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

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

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