Захват аудио
Ср янв 16, 2019 16:06:31
Добрый день!
Помогите сориентироваться плиз!
До этого занимался стеком UDP, таймерами, флешками, uart-ами, пока на 8-битных PIC-ах.
Хочу передавать звук, в "хорошем переговорном" качестве. Чтобы грубо говоря на другом конце линии RS-485 собеседник совершенно отчетливо понимал сказанное, ну, практически телефония. Аналоговую часть опустим. Но high-definition не требуется.
Вопрос - на чем лучше организовать захват-обжим-воспроизведение? Я в принципе собираюсь освоить STM32, на PICах это мутить не хочу.
Может для задачи ЗА ГЛАЗА хватит какого-нибудь простейшего аппаратного кодека? Какие они бывают, где про это почитать?
Ну в принципе после миграции на STM32 могу заморочится захватом средствами самой STM32, программно, вроде есть примеры, но вот надо ли?
(т.к там помимо передачи звука будет масса других задач)
Помогите сориентироваться плиз!
До этого занимался стеком UDP, таймерами, флешками, uart-ами, пока на 8-битных PIC-ах.
Хочу передавать звук, в "хорошем переговорном" качестве. Чтобы грубо говоря на другом конце линии RS-485 собеседник совершенно отчетливо понимал сказанное, ну, практически телефония. Аналоговую часть опустим. Но high-definition не требуется.
Вопрос - на чем лучше организовать захват-обжим-воспроизведение? Я в принципе собираюсь освоить STM32, на PICах это мутить не хочу.
Может для задачи ЗА ГЛАЗА хватит какого-нибудь простейшего аппаратного кодека? Какие они бывают, где про это почитать?
Ну в принципе после миграции на STM32 могу заморочится захватом средствами самой STM32, программно, вроде есть примеры, но вот надо ли?
(т.к там помимо передачи звука будет масса других задач)
Re: Захват аудио
Ср янв 16, 2019 22:58:10
Нет такого термина в нашей области. Циферки, циферки пожалуйста...vinni_puh писал(а):в "хорошем переговорном" качестве
А так, по простому - АЦП -> RS485 -> ЦАП. На скорости 128 кбод, можно передавать звук с качеством в 8 бит и частотой дискретизации = 16 КГц. Что сможет абсолютно любой МК, имеющий на борту UART и АЦП.
Такого качества хватит не только для речи. Музыку можно гонять спокойно.
Re: Захват аудио
Чт янв 17, 2019 00:43:36
В GSM протоколы и алгоритмы открыты, т.к. производителей оборудования (было) немеряно, а отраслевой стандарт должен быть примерно один, иначе телефон одного производителя не станет работать с базовой станцией другого. Голос там ужимали до передачи по каналу 9600 бод, насколько это "хорошее переговорное" качество, возможно, можете помнить сами. Если разговаривали по мобильному телефону GSM в конце 90-х - самом начале 2000-х. Если не помните, поверьте на слово - речь разборчива 
Аналоговую часть опускать не нужно, т.к. от неё будет ооочень зависеть качество. Кодек, предположительно, будет ограничивать верхний диапазон частот в звуке килогерц до 8-ми (больше для голоса не нужно). В GSM, если склероз меня не подводит, резали до 4-х кГц. Всё, что выше нужно будет убрать фильтрами в аналоговой части, чтобы оно не превращалось в шум и не мешало достоверной передаче полезного сигнала.
Аналоговую часть опускать не нужно, т.к. от неё будет ооочень зависеть качество. Кодек, предположительно, будет ограничивать верхний диапазон частот в звуке килогерц до 8-ми (больше для голоса не нужно). В GSM, если склероз меня не подводит, резали до 4-х кГц. Всё, что выше нужно будет убрать фильтрами в аналоговой части, чтобы оно не превращалось в шум и не мешало достоверной передаче полезного сигнала.
Re: Захват аудио
Чт янв 17, 2019 06:51:10
>>- АЦП -> RS485 -> ЦАП
Ну, это первое что родилось при обдумывании. Но получается приличный объем RAW-данных!?
Спасибо за комментарии!
По факту дело обстоит так. К устройству подходит RS-485 19200кб/с. (modbus). Устройств до 32, в "нормальном режиме"(без звука) по каналу будет летать телеметрия с датчиков.
При включении звука я ему буду выдалять .. ну никак не меньше 9600, с максимальным возможным сдвигом приоретизации для звука, но передача телеметрии остановиться не должна.
Отсюда предполагаю что компрессировать придется.
Со всеми этими датчиками наработки хорошие, но со звуком впервые сталкиваюсь, отсюда и вопросы.
Откуда цифра 19200 в RS 485? практика показала что с этим битрейтом можно забить на топологию линии (на практике - вообще - как хочешь так и ложат линию, с любым количеством веток любой длины... прямой линией даже отдаленно и не пахнет). При этом потери 0-2% - замеряю. Получается топология "расчески".
Требуется и дальше продолжить забивать. Но... может и получится отвоевать изменение тех.условий, и получится повысить ну максимум, до 27-28 кб/с. Тогда под звук смогу выделить пропорционально больше чем 9600.
Будет еще вариант исполнения с ethernet, но основной способ - RS-485.
И вот отсюда и предпосылки - ориентироваться на обработку средствами самой STM32, или существуют аппаратные кодеки?
Аналоговую часть в рамках этой темы планировал опустить)(а не вообще). Там подход самый серьезный будет, т.к квакающие, шипящие, булькающие, хрюкающие голосовые тракты до бешенства осточертели.
Ну, это первое что родилось при обдумывании. Но получается приличный объем RAW-данных!?
Спасибо за комментарии!
По факту дело обстоит так. К устройству подходит RS-485 19200кб/с. (modbus). Устройств до 32, в "нормальном режиме"(без звука) по каналу будет летать телеметрия с датчиков.
При включении звука я ему буду выдалять .. ну никак не меньше 9600, с максимальным возможным сдвигом приоретизации для звука, но передача телеметрии остановиться не должна.
Отсюда предполагаю что компрессировать придется.
Со всеми этими датчиками наработки хорошие, но со звуком впервые сталкиваюсь, отсюда и вопросы.
Откуда цифра 19200 в RS 485? практика показала что с этим битрейтом можно забить на топологию линии (на практике - вообще - как хочешь так и ложат линию, с любым количеством веток любой длины... прямой линией даже отдаленно и не пахнет). При этом потери 0-2% - замеряю. Получается топология "расчески".
Требуется и дальше продолжить забивать. Но... может и получится отвоевать изменение тех.условий, и получится повысить ну максимум, до 27-28 кб/с. Тогда под звук смогу выделить пропорционально больше чем 9600.
Будет еще вариант исполнения с ethernet, но основной способ - RS-485.
И вот отсюда и предпосылки - ориентироваться на обработку средствами самой STM32, или существуют аппаратные кодеки?
Аналоговую часть в рамках этой темы планировал опустить)(а не вообще). Там подход самый серьезный будет, т.к квакающие, шипящие, булькающие, хрюкающие голосовые тракты до бешенства осточертели.
Re: Захват аудио
Чт янв 17, 2019 07:13:45
Как раз сейчас пробую организовать похожий канал. Чем ниже битрейт UART тем больше дальность. Оцифровываю 8бит 8кГц. Без сжатия все красиво только 64кбод много. Простейший кодек ADPCM пока косячит. Ищу пример по GSM кодеку. Там 13кбод максимум.
Re: Захват аудио
Чт янв 17, 2019 07:26:53
Классический пример в моем случае - дом, 20 подъездов, по чердаку RS485, с чердака 20 ответвлений до 1 этажа, этажность 10-22. На чердаке центральная точка, с нее в антенну улетает на сервер, через IP-сеть.
На скорости 19200 пашет идеально. Если всплеск потерь хоть на одной точке - это пишется в базу и ремонтная бригада выезжает.
И вот туда хочу звук добавить.
На скорости 19200 пашет идеально. Если всплеск потерь хоть на одной точке - это пишется в базу и ремонтная бригада выезжает.
И вот туда хочу звук добавить.
Re: Захват аудио
Чт янв 17, 2019 07:55:09
Есть еще g726 кодек 16,24,32 кбод. 16 меня устроит, смотрю код, оцениваю затраты проца.
Re: Захват аудио
Чт янв 17, 2019 08:08:10
16.24 это можно в принципе...
Т.е Вы склоняетесь, процом обжимать?
Т.е Вы склоняетесь, процом обжимать?
Re: Захват аудио
Чт янв 17, 2019 08:21:25
STM32F0 на 65 МГц. Двойной буфер по 160 байт. Пока один отправляется, второй заполняется кодированными данными. Нужно успеть закодировать быстрее 75 мсек
Re: Захват аудио
Чт янв 17, 2019 08:53:47
можно и отдельный проц выделить под это..
Re: Захват аудио
Чт янв 17, 2019 11:23:30
Классический пример в моем случае - дом, 20 подъездов, по чердаку RS485, с чердака 20 ответвлений до 1 этажа, этажность 10-22. На чердаке центральная точка, с нее в антенну улетает на сервер, через IP-сеть.
На скорости 19200 пашет идеально. Если всплеск потерь хоть на одной точке - это пишется в базу и ремонтная бригада выезжает.
И вот туда хочу звук добавить.
На скорости 19200 пашет идеально. Если всплеск потерь хоть на одной точке - это пишется в базу и ремонтная бригада выезжает.
И вот туда хочу звук добавить.
Как вариант: вообще отказаться от RS-485 и передавать модемом. Сколько пролезет: зависит от стабильности характеристик линии (равномерности и стабильности её АЧХ). Но явно пролезет много больше чем с RS-485.
Не знаю только - хватит ли силёнок у дохлого STM32 на демодуляцию. Когда то делал подобные модемы на TMS320VC5502.
Re: Захват аудио
Пт янв 18, 2019 06:41:15
Допилил дифференциальное сжатие с нелинейным квантованием. 8кГц 8бит в поток 32 кбод. Пока многовато,но может сеть потянет на скорости 38400, ниже только 19200.
Добавил шумопонижение. Речь разборчива, почти не отличается от несжатого потока.
На оцифровку,код,декод и вывод звука STM32F030 расходует 2,5% процессорного времени.
Добавил шумопонижение. Речь разборчива, почти не отличается от несжатого потока.
На оцифровку,код,декод и вывод звука STM32F030 расходует 2,5% процессорного времени.
Re: Захват аудио
Пн май 20, 2019 18:16:21
Добрый день!
Как эксперименты с кодеком? У меня дошли руки, разобрался с АЦП-ЦАПом на АРМе, сейчас умею записывать-воспроизводить несжатый поток, выставлять битрейт, на CMSIS, победилось путем недолгого танца с бубном.
А где можно найти рабочие сорцы 726-го?
Как эксперименты с кодеком? У меня дошли руки, разобрался с АЦП-ЦАПом на АРМе, сейчас умею записывать-воспроизводить несжатый поток, выставлять битрейт, на CMSIS, победилось путем недолгого танца с бубном.
А где можно найти рабочие сорцы 726-го?
Re: Захват аудио
Пн май 20, 2019 19:58:06
Проект пока отложен. Мне нужно передавать поток по радио. Настройка радиоканала хромает. Из-за шума иногда появляется ошибка контрольной суммы,что приводит к искажениям. По проводу все идет красиво.