ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
29 марта
454398 Топик полностью
fk0, легенда (16.10.2013 12:12, просмотров: 209) ответил MegaJohn на Дано: выборки с АЦП. Хочу: передать через UDP и "чем-то" прослушать на компе. Есть что готовое чтобы воспроизвести чистый PCM или же примитивный распространенный протокол куда его завернуть ?
Протокол, кстати, актуальный вопрос. Почему: в реальных сетях будут потери, задержки отдельных пакетов и их переупорядочивание. Т.е. вариант с netcat хорошо работает только в ЛВС или через TCP. Но TCP может тормозить соединение повторными передачами когда они уже не актуальны. Я бы присмотрелся к RTP или чему-то аналогичному. Суть в том, что внутрь каждого пакета, как минимум, нужно положить последовательный номер даже не пакета (пакеты могут быть разного размера), а скорей некого виртуального смещения от начала проигрываемого файла (в сэмплах). Чтоб приёмная сторона могла переупорядочивать пакеты, дожидаться задержанных или продолжать проигрывание с пропуском. Ну и какой-то magic number для определения того, что это пакет того самого протокола, а не случайный пакет от какого-то другого (ну или версию протокола, частоту sample rate, используемый кодек и всё такое...) Потом размер пакета имеет значение. 1500 байт -- это очень большая задержка и очень большой пропуск при потере пакета. При передаче со скоростями 8..16кБит/с (Speex, AMR, G.729, GSM, не сырые данные) используют пакеты байт по 300 максимум. И здесь, конечно, неудобно, что высокие накладные расходы на UDP, IP, PPP и т.п. заголовки ("пол-пакета"). Наверное, стоит исходить из того, что пропуск одного пакета не должен катастрофически как-то восприниматься. Это десятки миллисекунд. Для сырых данных, особенно если это не u-law 8кГц, наверное, можно и 1.5килобайтные пакеты. Хотя они могут быть фрагментированы и дефрагментированы при передаче. И здесь возникает вероятность потери и, в отдельных случаях админов-идиотов, полная 100% потеря (блокировка ICMP в ситуации, когда IP протокол завёрнут внутрь IP и 1500 байт уже не лезет). При том, что TCP будет работать, но медленно и печально. Поэтому лучше, наверное, ограничиться где-то килобайтным пакетом. Ещё ньюанс -- кодеки типа GSM имеют функционал маскировки потери пакета. Честно говоря, не знаю как работает. Но как-то аппроксимирует пропущенный кадр, чтоб не включать тишину бьющую по ушам. Для сырых данных нужно что-то аналогичное. Например, повторить, при потере, последний кадр (если он короткий, 10-20...ну 50мс), причём плавно соединив его с предыдущим. Потому, что все резкие остановки вызывают щелчёк, и на старте, кстати, тоже. Когда большие колонки, а не мелкие наушники это особенно доставляет. Ввиду чего после кодека, видимо, полезен фильтр отрезающий частоты ниже 200Гц (для голоса), хотя он может быть и аппаратным, в усилителе.
[ZX]