МОДИФИКАЦИЯ ПРОГРАММНОГО КОМПЛЕКСА ГОЛОСОВОЙ СВЯЗИ «MUMBLE»

Введение

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

Описание программного комплекса

Программный комплекс «Mumble» представляет собой свободное кроссплатформенное VoIP приложение с открытым кодом. Комплекс состоит из двух программ: сервера «murmur» и клиентской программы «mumble»; архитектура: клиент – сервер (n-1).

Анализ исходной программы

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

Анализ приложения с помощью Performance monitor: запускаем Mumble, отключаем передачу голоса. В Performance monitor создаем сборщик данных, устанавливаем время сбора - 5 минут. Добавляем счетчик производительности, устанавливаем в нем сбор данных по затраченному времени процессора для процесса Mumble. Запускаем сбор данных, ждем 5 минут, программой Mumble не пользуемся. По истечении 5 минут открываем график потребления процессорного времени (Рис. 1). По графику видно, что в режиме ожидание программа имеет равномерно высокое потребление ресурсов. Средний процент процессорного времени примерно равен 20.

Рисунок 1 График потребления процессорного времени приложения Mumble в простое

Анализ приложения с помощью Process explorer: запускаем Process explorer и «Mumble», находим процесс «Mumble» в Process explorer. Открываем список его потоков. Из всех потоков выделяется один со значительным потреблением времени центрального процессора (Рис. 2). Включаем передачу данных в Mumble и проверяем изменения в потоках в Process explorer. В целом картина не изменилась, подозреваемый поток увеличил свою нагрузку (Рис. 3). Открываем стек этого потока (Рис. 4). В нем видим вызовы библиотеки Speex. Вызов speex_echo_cancellation (он наверняка соответствует функции подавления эха от колонок) говорит о том, что данный поток, скорее всего, используется для обработки звука с микрофона. В итоге: обнаружен поток, потребляющий большую часть ресурсов. Его потребление почти одинаковое вне зависимости от логического состояния программы (при включенной и выключенной передачи голоса). Данный поток выполняет обработку исходящего звука, то есть усилия по оптимизации, скорее всего, пойдут в эту область программы.

Рисунок 2. Список потоков Mumble      Рис. 3 Список потоков во время передачи.

Рисунок 4. Стек потока, потребляющего ресурсы.

Анализ исходного кода программы

Исходный код программного комплекса “Mumble” размещен на GitHub. Скачиваем его, устанавливаем и компилируем зависимости. Открываем проект клиентского приложения в QT Creator и выполняем поиск участка кода, вызывающего speex_echo_cancellation (Рис. 5).

Рисунок 5. Результат поиска метода speex_echo_cancellation в проекте Mumble.

Поиск показал, что метод speex_echo_cancellation библиотеки Speex вызывается только из одного метода. Данный метод (encodeAudioFrame) принадлежит классу AudioInput. Этот класс наследуется от QThread и представляет собой тот самый поток. Этот поток запускается и останавливается с помощью методов startInput и stopInput класса Audio. Изменим логику работы программы с помощью этих двух методов.

Разработка и реализация модификации

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

Тестирование модифицированной программы

Проведем два замера процессорного времени для новой версии приложения: 5 минут в режиме ожидания (Рис. 6) и 5 минут в смешанном режиме работы (Рис. 7). Результаты: 0.12 % в среднем в простое (в 166 раз меньше); 8.061 % в среднем в смешанном режиме работы (в 2 раза меньше).

Рисунок 6. График потребления процессорного времени в простое.

Рисунок 7. График потребления процессорного времени в режиме работы.

Заключение

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

Список литературы:

1. Бьерн Страуструп. Язык программирования С++. М.: Бином, 2011. – 1104 с.