@DOOMSDOY

Привет всем.
Ребят, что-то у меня дикий затуп, может кто подскажет как решить проблему, а то я уже на грани построения велосипеда из костылей.

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

Пока придумал такие пути решения проблемы:
<ul>- каким-то образом, периодически подстраивать чатоту на принимающей стороне (возможно, передавать в пакете тики таймера и сравнивать что натикало в приемнике за это же время. но время передачи пакета может быть разным и это усугубляет, какбэ)</ul><ul>- изначально настроить приемник так, чтобы он воспроизводил немного быстрее. что при этом будет уже сказал, но насколько сильно оно может повлиять на звук не знаю. что будет, если из потока с частотой дискретизации 22050 (условно) выбросить, скажем один из 40-ка сэмплов? и при этом тактирование желательно кварцовать на обоих сторонах, как я понимаю.</ul><ul>- перед сеансом связи ввести процедуру синхронизации.</ul><ul>- следить за заполненностью входного буфера и стремиться удерживать ее на уровне 50%, замедляя/ускоряя воспроизведение в каких-то рамках. тут боюсь, что при плохом качестве связи, и, соответственно, потере многих пакетов, можно поиметь "рывки" скорости. тут надо пробовать и играться.</ul>
Как лучше поступить, или может мне вобще надо менять общий подход?

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

0

@IT_Exp

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

0

@stt

Сколько лет подряд воспроизводить собираешься?))

0

@DOOMSDOY

Ну несколько (возможно десятков) часов.
Имеешь ввиду, что рассинхронизация будет происходить не насколько быстро и это не критично?

0

@Omkit5o

Личного опыта нет. теоретические основы "где-то видел". Что имею предложить:

Если есть возможность, делаете небольшую задержку воспроизведения, что бы в буффере у вас всегда было что воспроизвести в случае "тормозов отправителя". В случае опустошения буффера можно просто помолчать (неприятный эффект, но не должен происходить часто). А далее на подобие: Только в сторону увеличения. достигли 50% - воспроизвели 10 пакетом на 22060, далее вернули на стандартную.
Вообщем не держитесь 50%, держитесь чуть более широких границ.
Вставлять "тикер" смысла не вижу. Он и так "известен" по длине выборки.
И да, присоединяюсь к:

0

@stt

http://www.rtcs.ru/supplier_article_det ... =38&id=325

Добавил: Процесс передачи/приема пакетов разве не является процессом синхронизации устройств?

0

@DOOMSDOY

Вообщем то, изначально не было точного решения по поводу установки кварца на передающей стороне. Хотелось обойтись без оного. Но пока не поздно одуматься.
В целом, идею я понял. Спасибо.

Omkit5o, спасибо за ответ по существу. Чуток прояснили ситуацию. Пока это основной и наиболее приемлемый вариант по затратам ресурсов и общей "красоте" решения.

0

@Omkit5o

Всё же стоит одуматься. с кварцем звук будет "поприятнее", в том смысле что корректировки прийдеться проводить гораздо реже (если и прийдется). РЦ осциляторы же дают существенную ошибку (стм8 уходила на пол минуты в час, и это выше заявленной точности). В прочем это тоже может быть не критично.
Вспомнил ещё один вариант "синхронизации", применяемый в интернет вещании. Используются подстройка паузы. Когда "эфир" молчит, приемник подстраивает время этой тишины, что бы вернуть кеш в исходное состояние. В итоге вместо паузы в 1 секунду, будет у разных клиентов 0.5 -1.5с, а по скольку это тишина - не критично. Зато нет "искажения" сигнала подгонкой частоты дискретизации. Так что при наличии возможности втыкать паузы, почему бы и нет?

0

@Sym

Для синхронизации можно попробовать аккуратно вырезать куски звукового потока или вставлять пропущенные куски.

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

А изменение длительности звука, буквы, ноты на 1 мс вряд ли заметит самый искушенный слух.

Сам пробовал редактировать звуковые файлы таким образом, если заменить половину периодов, наблюдается забавное искажение звука, "роботизация" звука, в попсе такое часто используют, но слух не режет. И при том что половина звукового фрагмента синтезирована. Можете попробовать поредактировать wav файлы вручную, например растянуть или сжать его 5-10%, можно приноровиться сделать это без искажения звука, тональности. Если речь о рассинхронизации потока менее 1%, то задача еще проще.

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

http://phonograf.narod.ru/theory/image_16.gif

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


http://vyeytycymyxymuysar1.front.ru/060317_ossil_baba_papa.png

Картинка не идеальная, масштаб слишком крупный, но думаю понятно.

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

0

@IT_Exp

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

0

@Sym

В интернет вещании пауза может быть чистая, между треками при проигрывании музыки. А при сигнале с микрофона паузы может не быть, всегда будет шум какой-то.
Если у клиентов в буфере 1,5 секунды звука, это при 22 КГц частоте дискретизации 33 000 значений по 8 или 16 бит, не всякий микроконтроллер имеет столько памяти.

0

@Sym

У вас не сформулирована толком задача. Одно дело вы передаете симфонию Баха меломанам, которые услышат не то что выпадение куска буфера, но и на микросекундный джитер АЦП будут плеваться :)
Другое дело если это передача речи, там хоть половину сэмплов выбросить, речь останется разборчивой, хоть и искаженной.

По оборудованию тоже непонятно, держать буфер с данными, уже существенное требование к памяти, под 30-60 кбайт, вы вроде не против. А вот места для кварца уже нет, предполагаю что это какое-то совсем простое устройство.

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

Если там PIC16 без кварца и 100 байтами памяти, то лучшее что он может сделать это выкидывать лишние сэмплы, или придумывать их, с простой апроксимацией, линейной или квадратичной. Вот такой подход можно имитировать на компе, написав простую утилиту, и там уже смотреть, что будет при рассинхронизации на 0.1%, 1% или 10%.

0

@Sym

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

Главное успеть сформулировать слово, пока горит зеленая лампочка, и связь будет успешной :) А то буфер зальется и переполнится )))


http://operkor.files.wordpress.som/2010/04/d182d0b2-d0b2d0be-d0b7d0b0d0bbd0b8d0b2d0b0d0b5d182.jpg

0

@Ymk

насоветовали:)))

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

в буфере всегда должен быть запас на хотя бы 1 фрейм, коррекцию проводить по приходу пакета - сколько еще осталось в буфере. если меньше фрейма - убавить ЧУТЬ-ЧУТЬ частоту, если больше - добавить. имхо, релейного регулятора хватит (+1 попугай/-1 попугай к частоте на фрейм). разброс частот ограничить (он вообще должен быть маленьким, ибо +-50гц - это уже пипец много).

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

еще можно прореживать сигнал: слать фрейм в 2-3-4 пакета, в каждом пакете только 1е, 2е, 3и и т.д. отсчеты. если потерялся пакет - интерполируем. качество упадет, но пропадания сигнала не будет.

0

@DOOMSDOY

Спасибо всем отписавшимся. Пока думается, что частотозадающие кварцы на обеих сторонах и небольшая адаптивная подстройка скорости сэмплирования будет достаточной мерой. Это надобно еще немного посчитать будет, чтобы определиться для себя со степенью этой подстройки и пределами применимости.
По поводу задачи: ничего экстраординарного, передача голоса, в основном. Теплоламповое качество не требуется, но и разборчивость речи должна быть лучше, чем при 8 бит 8 кГц, и для дальнейшего применения хочется сформировать для себя какой-то подход, работающий и при немного изменившихся условиях.
Первоначальное нежелание устанавливать кварц обусловлено больше не сложностью/простотой устройства, а желанием минимизировать габариты. Хотя, сами по себе устройства и правда будут предельно простыми (в основе пока планируется STM8L152K4 или близкий). Да и в серьезной системе кто бы в здравом уме стал бы гнать сырой несжатый звук в таких условиях...
При 12бит АЦП получается, что два сэмпла помещаются в 3 байта, в пакет информации предполагается закатывать 30 байт (20 сэмплов). Десяток-второй (можно и больше) пакетов можно спокойно хранить в памяти.

Хоть девайсы и не серия, и можно было бы тупо экспериментально добиться приемлемой работы конкретной пары, но как-то я так не привык, хочется повторяемости...

0

@Sym

Если вы делаете подстройку, то кварц не нужен будет, частота так быстро не уплывет чтобы вызвать проблемы. Подстройку я имею ввиду постоянную, по мере прихода новых данных. Динные приходят быстрее чем воспроизводятся, клиент собрал немного статистики, увеличил частоту на 0.001%, не помогло, умножили шаг в 2 раза, увеличили частоту уже на 0.002%, в следующий раз на 0.004%. Если промахнулись начинаем заново, снизили частоту на 0.001% ... и так пока частоты не совпадут. Минимальный шаг на глаз можно сделать 0.001%, максимальное регулирование частоты +-20%, если уж сильно частота уплывет, на морозе например.

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

Тогда всё намного упрощается.

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

В случае пропадания связи поделать вообще ничего нельзя, можно с этим и не париться. Тут главное следить чтобы пропавшие сэмплы не исказили частоту сэмплирования, а то клиент "подумает" что он слишком быстро опустошает буфер и начнет тормозиться, до нижнего порога, до -20% например. Хотя это тоже мелочи, при восстановлении связи всё вернется на свое место. Проблема может быть если связь будет пропадать каждые 5 секунд на 1 секунду, но это уже не связь )

8кГц для голоса кстати вполне нормальная частота, больше и не нужно особо, на разборчивость никак не повлияет.

http://www.vmorozov.ru/content/view/144/56/


http://www.vmorozov.ru/images/stories/countertenors/fig.1.gif

22 кГц просто тонкости интонации передадут некоторые, особенно в женском голосе, на спектре там уровень -20 Дб, это сколько в разах, почти в 100 раз слабее основных, низкочастотных гармоник.

0

@Sym

Действительно, при точности нормального кварца

http://www.quartz1.ru/Q/Qdoc.htm

±3х10-6 от FНОМ. в диапазоне -10...+60°С
±7,5х10-6 от FНОМ. в диапазоне -30...+60°С

Проблема с лишним или пропущенным сэмплом будет реже чем 1 раз на 100 000 сэмплов, или 1 раз в 4 секунды, даже если приемник носить на мороз в -30 и сразу под обогреватель :) Проблема вообще исчезает. Думаю на слух заметить невозможно, можно в любом звуковом редакторе убедится.

Но это слишком простое решение :)

Это около 1% точности, с автоподстройкой частоты не критично.

0

@Ymk

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

0

@Woddy

кварцы с точностью 30ppm доступны без проблем.
это погрешность около 2.5 секунд в сутки.
делаем буфер 3 секунды и гарантированно играем музыку в течении суток.

для повторяемости результата нам надо только развести кварц в соответствии с даташитом.

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

0

@Woddy

подозреваю что больше проблем может доставить искажение / потеря данных...

0