Educational Technology & Society 10(4) 2007

ISSN 1436-4522

Голосовые коммуникации в виртуальных образовательных средах

В.П. Хованский1, А.В. Герасимов1, М.Н. Морозов1
1
Лаборатория систем мультимедиа
Марийский государственный технический университет, Йошкар-Ола, Россия

X_Vladimir@list.ru

аннотация

В работе показаны преимущества голосовых коммуникации в виртуальных образовательных средах и представлен подход к реализации голосовых коммуникаций в виртуальных образовательных средах. Автором рассмотрены основные проблемы реализации голосовых средств и их использования в виртуальных образовательных средах. Проводится обзор протоколов голосовой связи, аудио кодеков. Рассматривается структура программных компонентов и технические особенности реализации рассматриваемого подхода.

Ключевые слова

виртуальная среда, аватар, визема, 3D звук, кодек.

Введение

Среди систем электронного обучения всю большую популярность приобретают виртуальные среды (виртуальные миры). Виртуальная образовательная среда – это система, обеспечивающая поддержку группы учащихся, выполняющих в сотрудничестве общую учебную задачу, и в которой каждый участник представлен персонажем – 3D моделью человека. В них большую роль играют коммуникационные взаимодействия между учениками в текстовой и звуковой форме. Текстовые коммуникации не обеспечивают необходимой динамики (возникают паузы между сообщениями вследствие набора текста), а также не позволяют передавать эмоции и интонацию участников. Голосовые коммуникации, напротив, обеспечивают непосредственное общение между участниками. Проведенные эксперименты показывают, что применение голосовых коммуникаций внутри виртуальных образовательных сред повышает мотивацию участников данных сред к взаимодействию друг с другом (Moreno, 2002). Главный эффект «живого» голоса заключается в том, что участники начинают оценивать образ персонажа как более привлекательный и человекоподобный (Cleborne, Maddux, 2002).

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

1.        Соглашение о параметрах соединения между участниками (выбор протокола, кодека и так далее) (Kundan, 2006). Участники должны иметь один и тот же кодек для кодирования и декодирования голоса. При отправлении пакета с голосом в сеть пакет сжимается кодеком и для того, чтобы воспроизвести голос собеседника, участник должен иметь тот же самый кодек, что и у собеседника;

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

3.        Конфиденциальность общения. Данная проблема возникает из-за открытости протокола, из него возможен доступ к информации, представленной в телекоммуникациях (Kundan, 2006). Эта проблема в популярной системе Skype решается многочисленными кодировками информации;

В виртуальных мирах произносимая персонажем речь сопровождается анимацией губ, соответствующей воспроизводимым звукам. Многие звуки дают практически одинаковое положение губ. Такие звуки группируется в наборы звуков, которые будем называть виземами. Для придания более реалистичной формы общения используют технологию 3D звука, которая позволяет по воспроизводимому голосу примерно определить позицию говорящего участника в виртуальной среде относительно слушателя (Чупраков, 2006; Klein, 2005; SAFIR, 2004).

Голосовое общение

Протоколы голосовой связи

На сегодняшний день существуют два популярных протокола: протокол H.323 и SIP. Н.323 представляет собой так называемую зонтичную рекомендацию, состоящую из нескольких протоколов, используемых для различных целей и работающих совместно. Он включает в себя следующие рекомендации (спецификации протокола H.323):

-         Н.225.0, используемый для регистрации терминалов и установления соединения;

-         Н.245 для контроля сессии;

-         Н.332 для многоточечных конференций;

-         Н.235 для обеспечения безопасности;

-         Н.246 для взаимодействия с сетями коммутации каналов и так далее.

Первоначально Н.323 разрабатывался для мультимедийных коммуникаций в локальных сетях LAN без гарантии качества (QoS – Quality of Service – качество обслуживания), но в последствии был доработан для удовлетворения более жестких требований IP-телефонии. Автором данного стандарта (протокола H.323) является организация ITU-T. ITU-T (International Telecommunication Union) – Международный союз электросвязи или сокращённо МСЭ (англ. International Telecommunication Union, ITU) — международная организация, определяющая стандарты в области телекоммуникаций и радио.

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

SIP – Session Initiation Protocol (протокол управления сессиями) – используется для создания, изменения и разрыва "сессий" между одним или несколькими участниками. Понятие "сессии" в протоколе SIP достаточно широкое. Под "сессией" могут подразумеваться не только телефонные звонки, но и передача данных, конференции, децентрализованные игры и так далее (спецификации протокола SIP).

Разработкой протокола SIP занимался комитет MMUSIC организации IETF, поэтому в отличие от протокола H.323 (разработанного телефонистами из ITU-T) протокол SIP является более интернет-ориентированным и предназначен для предоставления несколько других, по сравнению с протоколом H.323, услуг.

Протокол SIP во многом схож с широко используемым протоколом HTTP, который также можно считать сигнальным (клиенты запрашивают у сервера нужные им документы). При установке соединения параметры сессии описываются в соответствии с SDP и вместе с заголовками протокола SIP передаются клиенту. Коды ответов протокола SIP также очень похожи на стандартные коды протокола HTTP. В случае удачного ответа клиенту посылается код 200, адрес не найден (код 404), ошибка авторизации (код 403) и др.

Протокол SDP (Handley, 1998) описывает параметры соединения. SDP используется исключительно для текстового описания сеанса и не имеет ни транспортных механизмов, ни средств согласований требуемых для сеанса параметров.

Клиенты SIP-сети идентифицируются по универсальным идентификаторам SIP-URI, внешне похожим на адреса электронной почты: sip:percei@mail.ru. Таким образом, имя клиента SIP состоит из персональной части (до знака @), идентифицирующей пользователя, и доменной части (после @), определяющей, например, организацию.

Описанные выше протоколы выполняют функции сигнализации, а непосредственно передачу голосовых данных осуществляет протокол RTP (RTCP).

Протокол RTP (Real-Time Protocol – протокол передачи данных в реальном масштабе времени) – это стандарт для передачи чувствительного к задержке трафика через сеть. Данный протокол работает на транспортном уровне поверх протокола UDP и используется при передаче трафика в реальном масштабе времени. Протокол отвечает за создание каналов, по которым будет проходить среда вызова (аудио-, видео- и обычных данных). Он определен группой IETF в спецификации RFC1889. Протокол RTCP (RTP Control Protocol) используется для информирования конечных точек о качестве распределения данных, которое обеспечивается каналом.

Протокол RTP переносит в своём заголовке данные, необходимые для восстановления голоса в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и так далее). А также в заголовке данного протокола передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты (Casner, 2003).

 

Аудио кодеки

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

-         G711 – стандартизованный ITU-T кодек, используемый в устройствах ISDN с требуемой пропускной способностью, равной 64 кбит/сек. Существуют две разновидности кодека u-law и a-law, отличающиеся алгоритмами кодирования. Кодек широко применяется всеми устройствами IP-телефонии.

-         G729 – стандартизованный ITU-T кодек, предназначенный для передачи речи с «хорошим качеством» при использовании небольшой пропускной способности (8 кбит/сек). Существуют две популярные (и несовместимые между собой) версии данного стандарта: Annex A (более "простая" схема кодирования) и Annex B (с использованием алгоритмов сжатия пауз). По субъективным оценкам, данный кодек обладает качеством лучшим, чем у G.723, но худшим, чем G711. Поддерживается практически всеми производителями оборудования. При коммерческом использовании требуется лицензия.

-         G.726 – кодек, стандартизованный комитетом ITU-T. Описывает технологию кодирования ADPCM (Джонатан, 2007) со скоростями сжатия 40, 32, 24 и 16 Кбит/с.

-         G723.1 – кодек, отличительной особенностью которого является возможность работы при очень низком потоке (5.3, 6.3 кбит/сек). Данный кодек стандартизованный ITU-T. По субъективным оценкам  кодек G723.1 обладает самым плохим качеством речи среди рассматриваемых кодеков. Поддерживается значительной частью устройств IP-телефонии. При коммерческом использовании требуется лицензия.

-         iLBC (Internet low bitrate codec) – открытый (не требующий лицензии) голосовой кодек. Данный кодек предназначен для кодирования голоса с пропускной способностью, равной 13.33 кбит/сек (при размере кадра 30 мс) и 15.20 кбит/сек (при размере кадра 20 мс). По субъективным оценкам экспертов (MOS – Mean Opinion Score –  "усредненная субъективная оценка экспертов"), качество речи данного кодека превышает G.729A. Кодек обеспечивает плавное снижение качества звука в случае потери фреймов за счет связи с потерянными или запоздавшими пакетами IP. Кроме того, кодек более устойчив (по сравнению с G729) к потере кадров, что позволяет эффективно использовать его при организации сеансов связи через сеть Интернет (Джонатан, 2007). Примером этому является популярная сеть IP-телефонии – Skype.

Сравнительные характеристики кодеков приводятся в таблице 1.

Таблица 1. Основные параметры кодеков IP-телефонии.

Кодек

Скорость передачи (Кбит/с)

Размер выборки (мс)

Размер

пакета (мс)

Оценка

MOS

G.711

64

0.125

0.125

4.1

G.729

8

10

15

3.92

G.726 ADPCM

32

0.125

10

3.85

G.723.1 MP-MLQ

6.3

30

37.5

3.8

G.723.1 ACELP

5.3

30

37.5

3.65

iLBC

13.33

30

30

3.9

iLBC

15.2

20

30

3.9

Таким образом, по показателю качества кодеки можно расположить следующим образом (в порядке улучшения качества): G723, G729, G.726, iLBC, G711. По используемой пропускной способности (в порядке уменьшения:) G711, G.726, G729, iLBC, G723. Итак, для нашей системы в локальной сети нам подходит кодек G711, а для Интернета кодек – iLBC.

Особенности реализации голосового общения в виртуальных средах

В настоящий момент существуют много библиотек, реализующие протоколы голосовой связи. Для реализации голосовых коммуникаций был выбран протокол H.323 (спецификации протокола H.323), который реализует библиотека OpenH323. С целью передачи и синхронизации визем были доработаны логические каналы, по которым передаются аудиоданные, и разработан виртуальный кодек, который перехватывает этапы кодирования и декодирование речи.

Разработанная система состоит из серверной части и клиентской части.

 

Серверная часть системы

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

Рис. 1. Принципы работы серверной части системы.

После инициализации сервер слушает порт 1720. Поступивший запрос на соединение клиента, сервер создает управляющий канал (отдельный поток) протокола H.245. В этом канале идет процесс установления соединения.

Затем сервер проверяет статус (идентификатор, имя приложения, используемый протокол) клиента. Дальше проверяется имя группы (указан в запросе клиента), если существует, то проверяем, есть уже такой участник в группе. При  наличии участника в данной группе отклоняем соединение с клиентом. После успешного присоединения или создания группы, идет обмен возможностями с клиентом. Затем, в случае успеха, создает два логических RTP-канала по передачи/приеме голосовых данных. Как показано на рис. 2, после успешного соединения для каждого клиента работают три потока (канала):

-         канал связи с клиентом, который обрабатывает управляющие сообщения клиента, и

-         RTP-каналы: логический канал приема голосовых данных и отправки данных, которые осуществляют прием, передачу звука, визем и другие данные (которые описаны ниже).

Рис. 2. Принципы работы канала связи.

При разъединении с клиентом, управляющий канал посылает сигнал RTP-каналам о завершении работы. При этом участник удаляется из группы и сама группа, если становится пустой. Управляющий канал завершает свою работу.

Сервер работает в одном из двух режимов:

1.        режим работы, в котором поступившие звуковые данные участников проходят этапы декодирования, микширования и кодирования (описано ниже);

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

 

Клиентская часть системы

Клиентская часть обеспечивает выполнение следующих функций:

-         запись речи участника с микрофона;

-         воспроизведение речи участника;

-         протоколирование речевых сообщений участника ВКС в виде набора звуковых файлов;

-         кодирование и декодирование речи;

-         выбор приоритетного кодека;

-         отправку и прием данных;

-         управлением режимом «разговора»;

На рис. 3 приведена структурная схема клиентской части системы. Стрелками показано движение данных от одного блока к другому.

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

1.        2D звук;

2.        3D звук.

Клиенты первого и второго режима могут подключаться только к серверу первого и второго режима соответственно.

 

Рис. 3. Структурная схема клиентской части системы.

Идентификация и визуализация голоса

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

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

На стороне сервера, при получении данных анализируется RTP-пакет. Из него извлекаются поток данных из дополнительного заголовка пакета. Полученные данные преобразуются в запись — идентификатор, позиция, ориентация аватара и визема, и поступают на вход блока анализа расположений и ориентаций аватаров. В данном блоке через определенные интервалы времени анализируется список записей, поступивших от участников одной групп. Для каждого участника конференции из данного списка формируется список пар (идентификатор аватара и визема), который упорядочен по расстоянию и ориентации между аватаром участника, которому отправляется данные, и между аватарами других участников. Данный список конвертируется в поток данных и включается в RTP-пакет в качестве дополнительного заголовка и отправляется клиенту.

Клиент принимает данный список пар (идентификатор аватара и визема), после чего список поступает в блок распознавания визем, в котором они периодически опрашиваются при обновлении 3D-сцены (рис. 4).

Рис. 4. виземы.

Алгоритм микширования

Сами звуковые данные поступают в модуль микширования: там они декодируются в 16 битные линейные сэмплы и добавляются в очередь буфера звука участника. Под сэмплом (sample) понимают цифровое отображение аналогового звука. Сэмплом также называют единицу измерения амплитуды в цифровой записи (Kundan, 2006). Каждый буфер маркируется соответствующей временной меткой протокола RTP. Шум приходящих пакетов фильтруется с помощью алгоритма задержки воспроизведения. В каждом выходном интервале пакетирования таймер запускает процедуру, которая микширует множество сэмплов с одного из многих входных буферов каждого активного участника в комбинированный пакет путем простого добавления значений сэмплов. Таймер корректирует вычисления времени задержки обработки в каждом интервале.

Чтобы позволить входным и выходным пакетам иметь различные интервалы пакетирования, процедура микширования извлекает сэмплы с одного или более входных буферов. Использование связанного списка буферов экономит память по сравнению с циклическим буфером максимального размера, и позволяет легко обнаружить, когда источник участника молчит. Для каждого из участников, значения линейного сэмпла с очереди участника (например, A) вычитается с микшированных данных X и в результате  данные (X–A) кодируются с использованием предпочтительного алгоритма компрессии звука участника A (рис. 4). Кодированные данные упаковываются и посылаются к данному участнику. Если M участников, тогда микширование и перераспределение будет брать M сложений и M вычитаний.

 

Рис. 5. Схема декодирования-микширования-кодирования.

Особенности реализации 3D звука

Использование 3D звука в виртуальных средах делает более реалистичным речь говорящего в виртуальном мире.

На рис. 5 показана схема воспроизведения речи участника (3D звука)

Для каждого аватара создается звуковой канал (но устройство вывода для воспроизведения звука для данного канала закрыт), и данный поток переходит в режим ожидания. При поступлении данных (RTP-пакета), анализируется его дополнительный заголовок, извлекается данные об идентификаторе аватара, ищется звуковой канал аватара, у которого идентификатор совпадает с поступившим. Затем после нахождения искомого канала, данные (звук и идентификатор аватара), извлеченные из основного заголовка RTP-пакета, поступает в блок «Обработка звуковых данных» данного звукового канала, в котором рассчитываются параметры 3D-звука (Чупраков, 2006; Klein, 2005; SAFIR, 2004), и, затем, по вычисленным параметрам происходит преобразования звука. При поступлении данных в список канал открывает устройство вывода для воспроизведения.

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

 

Рис. 6. Схема воспроизведения речи участника.

Анализ и оценка разработки

К достоинствам системы можно отнести следующие моменты:

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

-         использование средств визуализации голосового общения и технологии воспроизведения 3D звука придает большую реалистичность и человекоподобность персонажей виртуальной среды.

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

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

Заключение

Описанные программные средства голосовых коммуникации в Лаборатории систем мультимедиа были апробированы в системе поддержки голосового общения между участниками виртуальной среды «Английский язык. 8 класс». Использование системы голосового общения показало ее надежность и хорошее качество передачи данных. Пользователи системы с интересом восприняли открывшиеся возможности голосовых коммуникаций, что в большой степени оказало влияние на их мотивацию к работе в виртуальной среде.

Литература

[Дэвидсон Джонатан, 2007] Дэвидсон Джонатан, Питерс Джеймс, Бхатия Манож, Калидинди Сатиш, Мукхержи Судипто. Основы передачи голосовых данных по сетям IP, 2-е изд. : Пер. с англ. – М. : ООО “И.Д. Вильямс”, 2007. – 400 с. : –  Парал. тит. англ.

[Константин Чупраков, 2006] Константин Чупраков. Техника трехмерного позиционирования звука,  2006 (http://www.tmk.ru/articles/view.php?art=122).

[S. Casner, 2003] S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Protocol for Real-Time Applications, 2003 (http://www.rfc-editor.org/rfc/std/std64.txt)

[Cleborne D. Maddux, 2002] Cleborne D. Maddux, Dee LaMont Johnson, Jacque Ewing-Taylor – 2002. Distance Education: Issues and Concerns, 89, 131-135

[M. Handley, 1998] M. Handley, V. Jacobson. RFC 2327 - SDP: Session Description Protocol (http://www.faqs.org/rfcs/rfc2327.html), 1998

[Eric Klein, 2005] Eric Klein, Greg S. Schmidt, Erik B. Tomlin and Dennis G. Brown. Dirt-Cheap 3-D Spatial Audio. Linux Journal, 2005 (http://www.linuxjournal.com/article/8277).

[Kundan N. S., 2006] Kundan N. S. Reliable, Scalable and Interoperable Internet Telephony. COLUMBIA UNIVERSITY. 2006.

[Moreno, R., 2002] Moreno, R., & Mayer, R. E. (2002). Verbal Redundancy in Multimedia Learning:When Reading Helps Listening. Journal of Educational Psychology, 94(1), 156-163.

[Michael Schmitz SAFIR, 2004] Michael Schmitz SAFIR. Spatial Audio Framework for Instrumented Rooms. Saarland University, Saarbrucken, Germany. 2004 (http://w5.cs.uni-sb.de/~schmitz/publications/safir.pdf).

[спецификации протокола H.323] спецификации протокола H.323 http://www.packetizer.com/voip/h323

[спецификации протокола SIP] спецификации протокола SIP http://www.packetizer.com/voip/sip RFC1889.