Самодельный Ethernet-транспорт для аудиоинтерфейса.
- Автор темы Rst7
- Дата начала
Ну как бы всегда может случиться помеха например. На самом деле состояние повторной посылки пакета я в живую наблюдаю крайне редко. Для отладки пришлось специальную кнопку сделать "потерять пакет"
В общем-то стандарт 802.3 говорит, что Bit Error Rate должен быть не хуже, чем 10^-10. Т.е. для потока, скажем, в 50Мбит/с (ну это примерно по 16 каналов туда и обратно) имеем, что 10^10 бит пролетит за 200 секунд. И уже может появиться ошибка. Реально я наблюдаю менее одной перепосылки в сутки, а это значит, что BER лучше, чем 10^-12.
Ну как бы всегда может случиться помеха например. На самом деле состояние повторной посылки пакета я в живую наблюдаю крайне редко. Для отладки пришлось специальную кнопку сделать "потерять пакет"
В общем-то стандарт 802.3 говорит, что Bit Error Rate должен быть не хуже, чем 10^-10. Т.е. для потока, скажем, в 50Мбит/с (ну это примерно по 16 каналов туда и обратно) имеем, что 10^10 бит пролетит за 200 секунд. И уже может появиться ошибка. Реально я наблюдаю менее одной перепосылки в сутки, а это значит, что BER лучше, чем 10^-12.
Немного неожиданно (я думал там на уровне протокола что-нибудь типа кодов восстанавливающих ошибки используется)
чайник я в сетевых технологиях - очень интересно - спасибо!
аж руки зачесались ))) жаль работы дохрена
Добрый вечер!
Возможно немного не по теме, но я что-то не разобрался как личное сообщение отправить.
По результату чтения темы про Ethernet-транспорт хотелось бы спросить - совершенно случайно не занимались ли Вы передачей аудио по WiFi сети в реальном времени? Было бы здорово оценить возможные задержки при таком способе передачи. Условия те же - одной из устройств является микропроцессорным модулем с уникальной программой, другое - ПК, и пр.пр. с общераспространёнными ОС.
Возможно немного не по теме, но я что-то не разобрался как личное сообщение отправить.
По результату чтения темы про Ethernet-транспорт хотелось бы спросить - совершенно случайно не занимались ли Вы передачей аудио по WiFi сети в реальном времени? Было бы здорово оценить возможные задержки при таком способе передачи. Условия те же - одной из устройств является микропроцессорным модулем с уникальной программой, другое - ПК, и пр.пр. с общераспространёнными ОС.
Ну при использовании обычного оборудования буфер в десяток миллисекунд практически достаточно надежно гарантирует отсутствие щелчков. Это если нет помех от других сетей на выбранном канале. Если они есть - то там все совсем плохо становится.
Вы бы более развернуто задачу обрисовали, кстати.
@Rst7,
Я не стал подробно, ибо тема не моя. Но я действительно не понял как личные сообщения отправить.
Но по сути - интересно, можно ли с помощью обычных смартфонов, айфонов и пр. сделать концертную систему мониторинга.
В требованиях самой точки доступа мы не ограничены - устройство можно сделать и подогнать под задачи. А вот с клиентскими устройствами сложнее: максимум вмешательства - собственное приложение.
Если в готовом виде клиентское устройство не использовать - идея бессмысленна, точнее идея использования WiFi. Вопрос стабильности работы сети не последний, но для начала не ясно - будут ли приемлемы сами задержки протокола. 10 МС не мало.
Пскольку это сильно завязано на сетевой передаче аудио, думал может есть у вас опыт работы в этой области. Кроме того, ваше устройство может служить модулем ввода.
Я не стал подробно, ибо тема не моя. Но я действительно не понял как личные сообщения отправить.
Но по сути - интересно, можно ли с помощью обычных смартфонов, айфонов и пр. сделать концертную систему мониторинга.
В требованиях самой точки доступа мы не ограничены - устройство можно сделать и подогнать под задачи. А вот с клиентскими устройствами сложнее: максимум вмешательства - собственное приложение.
Если в готовом виде клиентское устройство не использовать - идея бессмысленна, точнее идея использования WiFi. Вопрос стабильности работы сети не последний, но для начала не ясно - будут ли приемлемы сами задержки протокола. 10 МС не мало.
Пскольку это сильно завязано на сетевой передаче аудио, думал может есть у вас опыт работы в этой области. Кроме того, ваше устройство может служить модулем ввода.
А нужно ли? Там же не только с задержками в WiFi вопрос, но и в том, что с выводом аудио на самом смартфоне тоже все не радужно.
На самом деле не так уж прям страшен черт, как его малюют. Вот, например, очень-очень альфа-версия именно цифрового мониторинга, но тем не менее оценить возможности и прайслист вполне уже можно.
Передатчик (он принимает данные через Ethernet из DAW, работая в паре с картой из стартпоста, правда, припаян только один радиомодуль, а вообще их должно быть 4, по числу каналов, каждый - стерео, понятное дело):
Приемник:
Он же с подключенной зарядкой и отладчиком:
48К, стерео, лишних 2мс к общей задержке. Питается от литиевой АКБ, мне хватает на пяток репетиций между зарядками. Габариты - 70*50мм.
Вот и нафига тут еще смартфон?
С которым совершенно непонятно, как бороться. Доступа к железу нет, только API для формошлепов и полностью скрытая реализация всего низкого уровня.
Я Вам больше скажу. Нет даже доступных в смысле полной документации на физический уровень микросхем, реализующих PHY+MAC для WiFi. Была бы возможность насиловать их на уровне регистров - может и можно было что-то придумать. А заниматься реверс-инжинирингом какого-нибудь WiFi-модуля - это слишком накладно по затратам рабочего времени.
PS Ах да, еще один веселый момент. У меня в модуле для раскачки наушников стоит повышающий преобразователь. Чего Вы ни в одном смартфоне не найдете.
Использовать смартфон в качестве приёмника НЕЛЬЗЯ!
Не сможете ни как совладать с задержкой аудио.
Тут вот специализированные устройства передатчик-приемник, не вай файные, дают минимум 4 мс плюс ко всем задержкам.
Не сможете ни как совладать с задержкой аудио.
Тут вот специализированные устройства передатчик-приемник, не вай файные, дают минимум 4 мс плюс ко всем задержкам.
Последнее редактирование:
Нет. Это достаточно тупые радиомодули, которые умеют только передать и принять сырой пакет. Весь протокол с синхронизацией, перепосылками и прочим - уже моим софтом.
по поводу кабеля -
10Gbase-T - витая пара категории 6а (до 100м)
кодирование - PAM-16 DSQ128
скорость - 833 Mbaud на пару + 3бита на символ + 4 пары
итого, один фрейм в 12 бит за 1/833000000 сек
при стандартном MTU=1500 передаем (1500-18)=1482 бит сырых данных - при 32бит на семпл - это 46 семплов
это (1482/12)=124 фрейма или 124/833000000=0,000000148859544 сек
итого, 1 32-битный семпл передаем за 0,000000003236077 сек
а например 96 таких семплов - за 0,000000310663396 сек или 0,000310663396 мс
а каналов вытащит - по 96 семплов на канал - 3219
это если без заголовков, без адресов и.т.п.
с ними, естественно меньше, но не кардинально
можно считать проще (без MTU и прочего):
1 канал занимает за 1мс - 32бит*96семплов=3072 бит/мсек
за секунду - 3072000 бит/сек
каналов в шланге - 10000000000/3072000=3256
железо - https://www.amazon.com/gp/offer-listing/B07C5VLVFF/ref=dp_olp_new_mbc?ie=UTF8&condition=new
90$ на одну сторону
кабель 6а - от 70р за метр готовый до 40р за метр в катушке.
10Gbase-T - витая пара категории 6а (до 100м)
кодирование - PAM-16 DSQ128
скорость - 833 Mbaud на пару + 3бита на символ + 4 пары
итого, один фрейм в 12 бит за 1/833000000 сек
при стандартном MTU=1500 передаем (1500-18)=1482 бит сырых данных - при 32бит на семпл - это 46 семплов
это (1482/12)=124 фрейма или 124/833000000=0,000000148859544 сек
итого, 1 32-битный семпл передаем за 0,000000003236077 сек
а например 96 таких семплов - за 0,000000310663396 сек или 0,000310663396 мс
а каналов вытащит - по 96 семплов на канал - 3219
это если без заголовков, без адресов и.т.п.
с ними, естественно меньше, но не кардинально
можно считать проще (без MTU и прочего):
1 канал занимает за 1мс - 32бит*96семплов=3072 бит/мсек
за секунду - 3072000 бит/сек
каналов в шланге - 10000000000/3072000=3256
железо - https://www.amazon.com/gp/offer-listing/B07C5VLVFF/ref=dp_olp_new_mbc?ie=UTF8&condition=new
90$ на одну сторону
кабель 6а - от 70р за метр готовый до 40р за метр в катушке.
Я так и полагал)) Потому и спросил, и не зря.
@Rst7, вещь интересная, может подумать как её на поток поставить?) На досуге, сам я из иной области разработок)) В каждой шутке лишь доля шутки)
Плохо только то, что вы пишите про 4 модуля на 4 канала. Не плохо было бы в один передатчик уложится, каналов на 8 хотя бы. Или хотя бы с запараллеливанием (приёмников). Чтобы мониторы мог весь оркестр использовать. (Там не нужно так много раздельных каналов). Можно туда небольшой ЖК дисплей и пару кнопок добавить - можно будет существенно расширить функционал по настройке звука под себя, или выбор каналов, заряд батареи и прочее.
не менее 11. и есть оговорка, что для некоторых режимов не менее 16. Детальнее нужно разбираться, но это и так много, поэтому не стоит того.
@Ifrit, из спортивного интереса и желания поучаствовать))) Технологии шагают вперёд и порой задумываешься как сделать доступными вещи, которые у серьёзных производителей стоят не малых денег. Возьмите любую систему мониторинга или радиомикрофон Sennheiser. А при передаче звука по цифре с последующей цифровой обработкой - часть проблем построения системы можно решить программно, а не аппаратно.
Что плохого-то? Центральный контроллер - один. На него навешано 4 радио-модуля (на фото передатчика - припаян только один). Каждый такой канал на своей частоте передает стереопару в соответствующий приемник.
Параллелить приемники тут не получится. Потому что еще есть перепосылка утерянных пакетов. Там двухсторонний обмен, с подтверждением приема.
Вы плохо смотрели. Там и есть небольшой OLED-дисплей и кнопки на приемнике.
Оркестр по сцене не бегает, а сидит. Ему проще проводами дать все в уши.
@Rst7, сложностью масштабирования. С частотами понятно - расширяем полосу пропускания.
Но мне кажется возможность параллельного подключения не была бы лишней. Смотрите, повтор пакета заложен в протокол, значит время на него есть. Пусть основное время приемник молчит, просыпаясь только при утере пакета (для этого передатчик будет давать паузы). Я понимаю, что тут же возникнет мысли о синхроне каналов, но ведь если пропущено пару пакетов - это не страшно и поправимо. А если пропущено много - он же не будет ждать, восстанавливать связь и досылать всё не ушедшее. По такому (плохому) принципу работают мои sony блютус наушники - пауза и попытка отослать все, что отстало. Но для прослушивания музыки это не критично, а для вокала в реальном времени)))))
Но мне кажется возможность параллельного подключения не была бы лишней. Смотрите, повтор пакета заложен в протокол, значит время на него есть. Пусть основное время приемник молчит, просыпаясь только при утере пакета (для этого передатчик будет давать паузы). Я понимаю, что тут же возникнет мысли о синхроне каналов, но ведь если пропущено пару пакетов - это не страшно и поправимо. А если пропущено много - он же не будет ждать, восстанавливать связь и досылать всё не ушедшее. По такому (плохому) принципу работают мои sony блютус наушники - пауза и попытка отослать все, что отстало. Но для прослушивания музыки это не критично, а для вокала в реальном времени)))))
@Aleksandr Oleynik, форум то "КБ"))
Вопрос в поиске новых решений, техника не стоит на месте)))
Другое дело, что тяжело эти решения искать - при стоимости материалов в 5к изделие будет стоить 15-20 на рынке (если не крупная серия и кучу-кучу условий).
Вопрос в поиске новых решений, техника не стоит на месте)))
Другое дело, что тяжело эти решения искать - при стоимости материалов в 5к изделие будет стоить 15-20 на рынке (если не крупная серия и кучу-кучу условий).
@Al-x, новые «самодельные» решения можно искать в среде уже имеющихся «не самодельных», когда есть уже хотяб отработанная элементная база, технологические реше6ия.
А при условии, что и Про решения пока не айс - что вы такого сможете найти?
Техника безусловно не стоит на месте, но вот в беспроводных технологиях, на мой взгляд, пока НИ КАКИХ прорывов.
Я читаю отзывы РЕАЛЬНЫХ пользователей ОЧЕНЬ Про решений беспроводных, и они часто густо негативные - то помехи, то пропадания, то пересечения.
Чем больше на одной сцене подобных устройств, тем хуже они будут работать.
Я вот купил для своих подобечный радио мониторинг от крепкой китайской компании с гарантией от немцев - писали, что одновременно можно использовать 10 устройств на разных каналах, по факту - больше пяти НЕ РЕАЛЬНО.
А при условии, что и Про решения пока не айс - что вы такого сможете найти?
Техника безусловно не стоит на месте, но вот в беспроводных технологиях, на мой взгляд, пока НИ КАКИХ прорывов.
Я читаю отзывы РЕАЛЬНЫХ пользователей ОЧЕНЬ Про решений беспроводных, и они часто густо негативные - то помехи, то пропадания, то пересечения.
Чем больше на одной сцене подобных устройств, тем хуже они будут работать.
Я вот купил для своих подобечный радио мониторинг от крепкой китайской компании с гарантией от немцев - писали, что одновременно можно использовать 10 устройств на разных каналах, по факту - больше пяти НЕ РЕАЛЬНО.
Последнее редактирование:
Никаких проблем с масштабированием. А вот с кучей параллельных приемников проблема есть - надо отказываться от перепосылки пакетов. Ну потому что неизвестно, кому не досталось. А вдруг всем разные, а количество свободных таймслотов ограничено.
Вы не поверите, но именно так оно и работает. Есть пустой таймслот для ответа приемника. Именно в это время приемник передает список недошедших до него пакетов в потоке.
Остальные слова я не очень понимаю. Постарайтесь более развернуто выражать свою мысль, не мешая мух и котлет.
На самом деле, если хотите экспериментов без перепосылки пакетов в формате "один передатчик - много приемников", то Вам сюда - https://www.aliexpress.com/item/TP-...c56c-42b9-9085-e7790c036175&priceBeautifyAB=0
Мобильная связь не имеет особого отношения к 2.4. Другое дело, что не все радиотракты устойчивы к сильным помехам от близких мобильных телефонов - тот же GSM при включении передатчика до ватта мощности в антенну дует, это может просто перегружать вход даже далеко отстоящего по частоте какого-нибудь ISM-band радиомодуля.
А так да, на 5ГГц заметно свободнее. Но пока нет готовых радиомодулей для передачи данных в этом диапазоне. Самому делать - это нужен комплект измерительного оборудования, но где ж его взять.
@Rst7, намек про ссылку: имеется ввиду, что сильно хуже будут работать? Или что уже есть и всё нормально?
Возможно я не прав. (И даже не прошу убеждать, просто поясню свое представление):
Допустим, потеряно несколько пакетов - мы пробуем это некоторое количество "потеряшек" пропихнуть через свободные слоты. Если потеряно несколько пакетов - они могут "догнать" поток. А если связь плохая и потерь много - мы же не можем поставить их в длительную очередь. Это же не музыка из проигрывателя - фонограмма, вокалист уже ушли вперёд.
Иными словами - повтор пакета тоже не панацея и поможет при работе в не очень хорошей среде, но лишь до некоторого уровня-предела. Из этого я делаю вывод, что сам по себе протокол с повтором имеет право на существование, но он не противоречит использованию нескольких приемников - серию пакетов можно повторить что для одного приемника, что для всех одновременно, если один потерял. Но время и количество повторов ограничены независимо от количества приимников - в случае сильных помех сигнал нельзя поставить в длинную очередь и пропихнуть все пакеты - сам звук уже давно уйдет вперёд.
Может даже будет эффективнее просто передавать данные по два раза?) Ещё можно попробовать использовать готовый или придумать свой алгоритм сжатия. Ясное дело не в mp3 (например, частично передавая измененный сигнал, а не все 16-24 бита.
Да, в этом смысле про 5 ГГц Вы правы.
Моя главная мысль была - использовать не дешёвые модули приемо-передатяиков, а в качестве базы взять ХОРОШИЙ роутер на 5Г, чтобы раздавать поток всем.
И так же использовать сравнительно не дорогие приемные модули. Но это были мысли человека, который не имел с этим дела в реальности. Потому то и советуюсь)))
@Aleksandr Oleynik, во-первых, я оптимист))) всегда хочется верить, что будут. Например, сейчас идут работы над оптической передачей wifi и скорости там заявляются значительно превосходящие современные радиомодули. Зона прямой видимости - да. Но в то же время - речь НЕ об узконаправленных как в китайских наушниках)
Возможно я не прав. (И даже не прошу убеждать, просто поясню свое представление):
Допустим, потеряно несколько пакетов - мы пробуем это некоторое количество "потеряшек" пропихнуть через свободные слоты. Если потеряно несколько пакетов - они могут "догнать" поток. А если связь плохая и потерь много - мы же не можем поставить их в длительную очередь. Это же не музыка из проигрывателя - фонограмма, вокалист уже ушли вперёд.
Иными словами - повтор пакета тоже не панацея и поможет при работе в не очень хорошей среде, но лишь до некоторого уровня-предела. Из этого я делаю вывод, что сам по себе протокол с повтором имеет право на существование, но он не противоречит использованию нескольких приемников - серию пакетов можно повторить что для одного приемника, что для всех одновременно, если один потерял. Но время и количество повторов ограничены независимо от количества приимников - в случае сильных помех сигнал нельзя поставить в длинную очередь и пропихнуть все пакеты - сам звук уже давно уйдет вперёд.
Может даже будет эффективнее просто передавать данные по два раза?) Ещё можно попробовать использовать готовый или придумать свой алгоритм сжатия. Ясное дело не в mp3 (например, частично передавая измененный сигнал, а не все 16-24 бита.
Да, в этом смысле про 5 ГГц Вы правы.
Моя главная мысль была - использовать не дешёвые модули приемо-передатяиков, а в качестве базы взять ХОРОШИЙ роутер на 5Г, чтобы раздавать поток всем.
И так же использовать сравнительно не дорогие приемные модули. Но это были мысли человека, который не имел с этим дела в реальности. Потому то и советуюсь)))
@Aleksandr Oleynik, во-первых, я оптимист))) всегда хочется верить, что будут. Например, сейчас идут работы над оптической передачей wifi и скорости там заявляются значительно превосходящие современные радиомодули. Зона прямой видимости - да. Но в то же время - речь НЕ об узконаправленных как в китайских наушниках)
Последнее редактирование:
@digilab2, это надо для всего, вообще-то.
Ну а зачем нужен был для звука эзернет?
А вот жеж - про него то и тема эта и к звуку имеет самое прямое отношение.
Кабели, ДЛЯ ПЕРЕДАЧИ ВСЕГО, это пережитки прошлого, и абсолютно ясно, что в ближайшем будующем на «последней мили» их не останется ни для чего.
Вот только В ДАННЫЙ МОМЕНТ искать способ надёжного и качественного решения беспроводного звука «самоделкину» - задача не благодарная, пусть этим пока монстры позанимаются и понавыпускают стандартных решений и компонентов для них.
Ну а зачем нужен был для звука эзернет?
А вот жеж - про него то и тема эта и к звуку имеет самое прямое отношение.
Кабели, ДЛЯ ПЕРЕДАЧИ ВСЕГО, это пережитки прошлого, и абсолютно ясно, что в ближайшем будующем на «последней мили» их не останется ни для чего.
Вот только В ДАННЫЙ МОМЕНТ искать способ надёжного и качественного решения беспроводного звука «самоделкину» - задача не благодарная, пусть этим пока монстры позанимаются и понавыпускают стандартных решений и компонентов для них.
Любой способ - хоть перепосыл, хоть дублирование, хоть Forward Error Correction - они хороши до некоторого предела. Просто они улучшают соотношение ошибок и нормальных пакетов. Если это соотношение падает до незаметного - то все хорошо.
Хоть какой хороший не возьмите, но есть две проблемы. CSMA-CD (недетерминированное время старта передачи в среде) и неадекватное поведение линуховых стеков при маршрутизации (слишком много лишнего ума).
И дело не в "дешевых модулях". Эти "дешевые модуля" позволяют решить задачу, а хваленый WiFi, который вроде бы есть в каждом утюге - нет.