Proceedings 2001

Система речевой связи через Интернет

А.Б.Маховиков, К.В.Столяров

 

 

Введение

 

Обычно в приложениях, реализующих речевую связь через Интернет, в качестве транспортного протокола для передачи данных используется Transmission Control Protocol (TCP). Этот протокол обеспечивает гарантированную доставку данных и успешно применяется в случае образования надежного канала связи. Если же канал получается ненадежным и наблюдается потеря данных, то возникает их повторная передача. Это приводит к увеличению задержек доставки речевых данных и качество диалога быстро падает. Каждому собеседнику приходится по несколько секунд, десятков секунд и даже минут ждать реакции на свою реплику от партнера. Чтобы устранить этот недостаток для передачи данных используют UDP. Этот протокол допускает потерю данных, но позволяет организовать речевую связь с фиксированной задержкой.

В системах для речевой связи через Интернет, использующих TCP, обычно применяют Code Excited Linear Predictive (CELP) кодеки [1,2,3], которые обеспечивают приемлемое качество восстановленной речи при относительно низких скоростях (4800-9600 бит/c) и требуют сравнительно небольших вычислительных затрат (5-10 Million Instructions Per Second (MIPS)). К сожалению, использованиеCELP кодеков в системах, использующих UDP, затруднительно. Для синтеза текущего окна речевого сигнала на приемной стороне CELPкодеку необходимо иметь информацию о сигнале возбуждения для предыдущего окна анализа. В случае потери пакета с предыдущим окном будет использован сигнал возбуждения из последнего синтезированного окна, в результате чего, восстановление сигнала в текущем окне будет произведено неверно. Поскольку все остальные приходящие пакеты будут тоже синтезироваться неверно, то потеря одного пакета автоматически приводит к окончанию разговора. Используемые в описываемой системе кодеки лишены этого недостатка. Каждое окно кодируется независимо. Потеря любого окна или последовательности окон не вызовет сбоя и при разговоре будет заменена паузой. При получении последующих окон синтез речи автоматически возобновится.

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

 

 

1. Краткое описание кодеков

 

          Речевой сигнал (16 бит, моно, 8000 Гц) пропускается через полосовой фильтр, образованный двумя фильтрами Баттерворда 3-го порядка – нижних и верхних частот и разбивается на последовательность окон. Каждое окно содержит 1440 отсчетов (180 мс). Записанное окно анализируется, но для передачи кодируются 120 отсчетов предыдущего окна и только 1320 отсчетов текущего (в сумме 1440 отсчетов) (рис. 1).

Процесс кодирования окна содержит три этапа. На первом этапе окно делится на несколько блоков одинаковой длины. Для каждого блока вычисляются, квантуются и интерполируются коэффициенты линейного предсказания и коэффициенты весового фильтра, учитывающего критерий слухового восприятия. На втором этапе вычисляются начальные параметры адаптивной кодовой книги, которая одновременно является оптимальным сигналом возбуждения для фрагмента первого блока. На третьем этапе вычисляется сигнал возбуждения для оставшейся части кодируемого окна. Поиск оптимальных параметров сигнала возбуждения во втором и третьем этапах реализован в виде алгоритма “анализ по синтезу”. Передаче подлежат коэффициенты линейного предсказания в виде линейных спектральных частот, начальные параметры адаптивной кодовой книги и параметры, необходимые для синтеза сигнала возбуждения для оставшейся части окна. На приемном конце на основе переданных параметров формируется сигнал возбуждения и подается на синтезирующий фильтр, образованный коэффициентами линейного предсказания (КЛП). Процедура кодирования КЛП для описываемых кодеков идентична. Записанное окно разбивается на 6 одинаковых блоков длиной по 240 отсчетов. Для каждого блока выполняется следующая последовательность действий: взвешивание окном Хэмминга, расчет КЛП с помощью алгоритма Дурбина, расширение формант, квантование и интерполяция КЛП, расчет коэффициентов фильтра, учитывающего критерий слухового восприятия. Квантование и интерполяция КЛП осуществляется в области линейных спектральных частот. На кодирование КЛП одного блока отводится 34 бита, а для всего окна соответственно 6*34=204 бита.

          Этап поиска начальных параметров адаптивной кодовой книги выполняется для первых 180 отсчетов кодируемого окна. Найденные параметры одновременно служат оптимальным сигналом возбуждения для этого отрезка. Сигнал состоит из последовательности импульсов. Каждый импульс характеризуется своей амплитудой и местоположением. Детальный алгоритм поиска оптимальных параметров импульсов описан в [4]. Здесь мы ограничимся лишь кратким его описанием.

Поиск оптимальных параметров для каждого импульса выполняется на отдельных участках одинаковой длины, на которые разбивается отрезок из 180 отсчетов. Для кодеков на 4800 бит/c и 9600 бит/с этот отрезок разбивается на 23 участка (22 участка длиной по 8 отсчетов и 23-й участок длиной 4 отсчета). Для кодека на 19200 бит/с – на 45 участков длиной по 4 отсчета. На каждом участке может находиться только один импульс. Количество битов на кодирование первых 180 отсчетов для каждого кодека приведено в таблице 1.

 

Таблица 1.

Количество битов на кодирование первых 180 отсчетов речевого сигнала

Кодек	Амплитуда, бит	Местоположение, бит	Число импульсов	Всего, бит
4800	6	3	23	207
9600	7	3	23	230
19200	7	2	45	405

 

Процедура поиска параметром сигнала возбуждения для оставшейся части кодируемого окна длиной 1260 отсчетов (1440-180=1260) осуществляется на третьем этапе и для каждого кодека имеет свои особенности.

Для кодека на 4800 бит/с оставшаяся часть окна из 1260 отсчетов разбивается на 21 участок длиной по 60 отсчетов. Для кодирования сигнала возбуждения на каждом участке с помощью алгоритма “анализ-по-синтезу” вычисляются четыре параметра: задержка и коэффициент усиления для адаптивной кодовой книги (АКК), и коэффициент усиления и номер для алгебраической кодовой книги (АлКК) [5]. Параметры для АлКК вычисляются только для четных участков (2,4,…,20). Раскладка битов для кодирования оставшейся части окна выглядит следующим образом:

 

 

-        задержка АКК                                         – 7 бит;

-        коэффициент усиления АКК                   – 7 бит;

-        номер АлКК                                            – 9 бит;

-        коэффициент усиления АлКК                 – 6 бит;

 

-        кодирование 11 нечетных участков        – 14*11=154 бита;

-        кодирование 10 четных участков           – 29*10=290 бит;

 

-        итого                                                        – 154+290=444 бита.

Для кодека на 9600 бит/c оставшаяся часть окна разбивается на 42 участка длиной по 30 отсчетов. Сигнал возбуждения на четных участках кодируется задержкой и коэффициентом усиления для адаптивной кодовой книги (АКК), а на нечетных участках – дополнительно добавляются три импульса. Каждый импульс характеризуется своей амплитудой и местоположением. Первый импульс может находиться только в первой трети участка, второй – во второй и третий – в третьей. Раскладка битов для кодирования оставшейся части окна:

 

-        задержка АКК                                         – 7 бит;

-        коэффициент усиления АКК                   – 7 бит;

-        местоположение импульса                      – 4 бита;

-        амплитуда импульса                                – 7 бит;

 

-        кодирование 21 нечетного участка         – 47*21=987 бита;

-        кодирование 21 четного участка            – 14*21=294 бит;

 

-        итого                                                        – 987+294=1281 бит.

 

Для кодека на 19200 бит/с оставшаяся часть окна разбивается на 84 участка длиной по 15 отсчетов. На каждом участке сигнал возбуждения кодируется следующим набором параметров: задержкой и коэффициентом усиления для адаптивной кодовой книги (АКК) и парой импульсов. Для последнего 84 участка кодируются только параметры АКК. Раскладка битов для кодирования оставшейся части окна:

 

-        задержка АКК                                         – 7 бит;

-        коэффициент усиления АКК                   – 7 бит;

-        местоположение импульса                      – 3 бита;

-        амплитуда импульса                                – 7 бит;

 

-        кодирование 83 участков                        – 34*83=2822 бит;

-        кодирование 84-го участка                     – 14 бит;

 

-        итого                                                        – 2822+14=2836 бит.

 

В таблице 2 приведено общее количество бит для кодирования всего окна в каждом кодеке.

 

Таблица 2.

Сводная информация по кодекам

Кодек	КЛП, бит	180 отсчетов, бит	1260 отсчетов, бит	Всего, бит	Фактическая скорость, бит/с	Степень сжатия, раз
4800	204	207	444	855	4750	26.9
9600	204	230	1281	1715	9528	13.4
19200	204	405	2836	3445	19139	6.7

 

 

2. Протокол для полнодуплексной звуковой связи

 

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

Для оценки качества канала связи необходимо знать среднюю сетевую задержку T_N и количество потерянных при передаче пакетовP_L. Чтобы получить эти два параметра, требуется посылать пакеты на удаленный компьютер и ждать их возвращения. Тогда, зная время посылки t₁ и время приема t₂ пакета, а также количество посланных P_S и вернувшихся назад P_R пакетов можно вычислить необходимые параметры:

T_N = ( t₂ – t₁ ) / 2 ,  P_L = P_S – P_R .

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

Служебные пакеты посылаются пачками. Каждая пачка содержит M пакетов. Пакеты в пачке посылаются с периодом T₁. Пачки посылаются с периодом T₂>M*T₁ либо в момент смены состояния. Все пакеты в пачке содержат одинаковые данные: номер, состояние иидентификатор пользователя. Номера позволяют игнорировать опоздавшие пакеты. Состояние сообщает, что необходимо делать удаленному пользователю. Идентификатор пользователя нужен для различия пакетов по признаку “свой-чужой”. Такой подход уже был нами использован в [4].

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

-        DT₁ – время записи окна, мс

-        DT₂ – время для кодирования окна, мс

-        DT₃ – время передачи окна по сети, мс

-        DT₄ – время для создания звуковой очереди, мс

-        DT₅ – время для декодирования пакетов в звуковой очереди, мс

В предлагаемой системе были выбраны следующие значения:

-        DT₁ = 180 мс;

-        DT₂ – зависит от процессора (для работы в реальном масштабе времени должно быть меньше значения DT₁);

-        DT₃ – из наших экспериментов был получен следующий наиболее вероятный диапазон значений [100,900] мс;

-        DT₄ – для компенсации сетевой задержки DT₃ необходимо, чтобы это значение было больше чем max(DT₃)=900 мс;

-        DT₅ – зависит от процессора.

На компьютерах с процессорами класса Pentium II значениями DT₂ и DT₅ можно пренебречь. Поэтому, при условии малой сетевой задержки DT₃, общая задержка в одну сторону составит 1-1.3 секунды. При хороших условиях связи дополнительное уменьшение задержки может быть получено за счет уменьшения времени для создания звуковой очереди. На компьютерах, загруженных большим количеством задач, значительно уменьшение времени DT₄ может привести к прерываниям звука при воспроизведении.

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

Процесс образования звуковой связи состоит из следующих шагов:

ШАГ 1.        С компьютера 1 компьютеру 2 посылаются служебные пакеты с состоянием CONNECTING.

ШАГ 2.        Получив эти пакеты, компьютер 2 переходит в состояние CONNECTED и возвращает пакеты обратно.

ШАГ 3.        По возвращению своих пакетов компьютер 1 также переходит в состояние CONNECTED.

ШАГ 4.        Компьютеры соединились и можно переходить в состояние разговора (TALKING).

 

Алгоритм поддержания звуковой связи состоит из следующих шагов:

ШАГ 1.        Ждем первого звукового пакета с любым номером.

ШАГ 2.        Получили первый звуковой пакет с любым номером.

ШАГ 3.        Ждем DT₄ мс:

DT₄ = ( N - 1 ) * DT₁ = 4 * 180 = 720 мс

N - число пакетов для создания звуковой очереди ( N = 5 )

За это время надеемся, что прибудут следующие N-1 пакетов.

ШАГ 4.        Поскольку первый пакет мог опоздать, то за время DT₄ в списке могло накопиться больше чем N пакетов. Поэтому для поддержания постоянной задержки DT номер первого пакета start_packet вычислим как:

start_packet = Nlast - N + 1

wait_packet  = start_packet

play_packet  = start_packet

где     Nlast            - номер последнего пакета в списке

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

wait_packet - номер ожидаемого пакета;

play_packet - номер последнего пакета, отправленного на воспроизведение.

Если список по каким-то причинам пуст, то

start_packet = 1

wait_packet  = start_packet

play_packet  = start_packet

Запоминаем текущее время start_time.

ШАГ 5.        Распаковываем N пакетов, накопленных в списке, и отправляем их на воспроизведение. Воспроизведение начнется в тот момент, когда в буфере воспроизведения накопится минимум M пакетов. Для реализации задержки T необходимо, чтобы M <= N. Весь процесс выглядит следующим образом:

Цикл от 1 до N:

5.1. Запрашиваем из списка пакет с номером wait_packet.

ЕСЛИ такой пакет существует ТО

- забираем его из списка;

- удаляем в списке все пакеты с меньшими номерами;

- распаковываем пакет.

ИНАЧЕ

- формируем "пакет-паузу".

5.2. Отправляем пакет на воспроизведение.

5.3. wait_packet = wait_packet + 1

5.4. play_packet = play_packet + 1

ШАГ 6.        Входим в главный цикл распаковки и воспроизведения пакетов:

ГЛАВНЫЙ ЦИКЛ:

6.1. ЕСЛИ состояние DISCONNECTED ТО переход на ШАГ 1.

6.2. Запрашиваем из списка пакет с номером wait_packet.

ЕСЛИ такой пакет существует ТО

- забираем его из списка;

- удаляем в списке все пакеты с меньшими номерами;

- распаковываем пакет;

- отправляем пакет на воcпроизведение;

- play_packet = wait_packet;

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

ИНАЧЕ

-        ЕСЛИ (список пуст) и (удаленное состояние

CONNECTED) ТО переход на пункт 1.

-    вычисляем номер воспроизводимого в данный момент  пакета (playing_packet);

-    ЕСЛИ playing_packet < wait_packet TO

- ждем 1/5 длительности пакета (надеемся, что пакет успеет прийти);

- переход на пункт 6.1.

ИНАЧЕ

- wait_packet = playing_packet + 1;

- запрашиваем из списка пакет с номером больше чем play_packet, но меньше чем wait_packet;

ЕСЛИ такой пакет существует ТО

- получаем его номер и кладем его в play_packet;

- удаляем из списка пакеты с меньшими номерами;

- распаковываем пакет;

- отправляем его на воспроизведение;

- корректируем wait_packet.

- переход на пункт 6.1.

Дополнения к алгоритму поддержания звуковой связи:

1. В список пакеты поступают из приемника.
2. Пакеты в списке автоматически сортируются по номерам.
3. Номер ожидаемого пакета wait_packet вычисляется по таймеру.

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

 

 

 

3. Система речевой связи

 

На основе описанных кодеков и процедуры образования звуковой связи была разработана простая система, позволяющая осуществлять диалог точка-точка через Интернет или локальную сеть. Интерфейс системы показан на рис.2. Используемый кодек определяется при старте программы. Чтобы осуществить связь, в полях “Remote IP address” и “Remote port” пользователь вводит соответственно IP-адрес и порт удаленной машины. Затем нажимает кнопку “Connect” для реализации соединения.

 

Рис. 2. Интерфейс экспериментальной системы речевой связи.

 

При успешном соединении пользователь переходит в состояние “Connected”, а в полях “Delivered packets, %” и “Deliver delay, ms”появляются соответственно процент вернувшихся назад служебных пакетов и среднее время прохождения этих пакетов в одну сторону. Информация в этих полях обновляется каждые 6 секунд. В состоянии “Connected” кнопки “Talk”, “Pause” и “Disconnect” становятся активными. При нажатии на кнопку “Talk” будет производиться запись, кодирование и отправка речи на удаленную машину. Если необходимо на время прервать речевой поток, то следует нажать кнопку “Pause”. Для окончания сеанса связи требуется нажать кнопку“Disconnect”. В полях “Remote state” и “Local state” можно наблюдать текущее состояние удаленной и своей машины.

 

Заключение

 

Наши разработки, описанные в данной статье, были использованы в проекте “etalkRadio”, который предусматривает организацию живых шоу в Интернет. Ознакомиться с ним можно по адресу http://www.etalkradio.net.

 

 

Литература

 

1. Binush S.A. "Predictive coding of speech at low bit rates". IEEE Transactions on Communications, Vol. 30, NO. 4, April 1982, pp. 600-614.
2. Kleun W.B., Krasinski D.J., Ketchum R.H. "Fast methods for the CELP speech coding algorithm". IEEE Transactions on Acoustic, Speech and Signal Processing, Vol. 38, NO. 8, August 1990, pp.1330-1341.
3. Langi A., Grieder W., Kinsner W. "Fast CELP algorithm and implementation for speech compression". Proc. Digital Communications Conference, 1994.
4. Machovikov A., Stolyarov K. "The FAST 4800 bps Codec for Internet Applications," Proc. of "4th World Multiconference on Systemics, Cybernetics and Informatics".- Orlando, Florida, U.S.A., 2000.
5. Kao Y.H. "A new deterministic codebook structure for CELP speech coding". Technical research report University of Maryland, 1990.