W5500_client+Atmega8_для самых начинающих.

[jcxz]

[uquote="PavelPic",url="/forum/viewtopic.php?p=4739326#p4739326"]Можно допаять ОЗУ, но сколько выгоды от этого я получу?[/uquote]ОЗУ - это устройство с произвольным доступом. И на порядки более быстрым, чем SD. Ваша затея напоминает, как если бы кто-то хотел себе дом, и потому купил собачью конуру и затем при помощи напильника пытался доработать её до полноценного дома. Зачем? Каждая задача требует адекватных инструментов для своего решения.
[uquote="PavelPic",url="/forum/viewtopic.php?p=4739326#p4739326"]jcxz, не все слушают сутками, сегодня 3 часа, завтра 0 часов.[/uquote]Т.е. - вы создаёте такое радио, которое надо будет включать по расписанию? А если случайно заснул и забыл выключить - наутро нужно искать новую SD-карту???
Радио - это такая вещь, которую включил и оно играет и играет, фоном. Если ещё и думать - сколько оно там по таймеру поиграло, чтобы вовремя выключать??.. ну нафиг такое "радио"!...
[uquote="PavelPic",url="/forum/viewtopic.php?p=4739326#p4739326"]Про поддержку HTTPS согласен. Я только начал библиотеку писать для интернет радио, со временем добавлю когда жизнь заставит.[/uquote]На Атмеге? Серьёзно??? Думаете - она потянет TLS?
Чтобы примерно представляли о чём идёт речь - загрузка CPU в моём радио:

1. Проигрывание потока MP3 станции 320 кб/с, стерео, HTTP = до ~26% http://icecast.vgtrk.cdnvideo.ru/vestifm
2. Проигрывание потока AAC станции 160 кб/с, стерео, HTTP = до ~27% http://lr4mp1.latvijasradio.lv:8018
3. Проигрывание потока AAC+ станции 48 кб/с, стерео, HTTP = до ~48% http://stream.grad-petrov.ru:8093/aac
4. Проигрывание потока AAC+ станции 96 кб/с, моно, HTTPS = до ~34% https://live.radiospinner.com/etkvkz-96
5. Проигрывание потока MP3 станции 256 кб/с, стерео, HTTPS = до ~32% https://stream.cassiopeia-station.ru:5125/stream
Самый тяжёлый вариант был бы на высоких скоростях для AAC+, стерео, HTTPS. Но станция AAC+, стерео, 128кб/с, HTTPS, которую раньше использовал для тестов, сейчас не работает. Раньше на ней загрузка CPU была 70...80%. Другую аналогичную, но работающую - к сожалению не знаю.

Это на Cortex-M4F с тактовой = 96МГц и с буферами в SDRAM.
Загрузка - суммарная: скачивание (WiFi через ESP8266), TLS (soft AES), декодирование аудио (Helix), обновление бегущей картинки на LCD 320x240, и много другой мелочи.
Загрузка CPU на HTTPS очень сильно зависит от размеров кусков кодирования потока: при больших кусках (по неск. КБ) загрузка сильно прыгает, при мелких кусках - более равномерная. Также многие станции отдают поток очень неравномерно: могут несколько секунд гнать на скорости в несколько раз выше скорости аудио-потока, потом пауза и снова - следующая порция. Некоторые сначала (сразу после подключения) выплёвывают большой объём (до 1МБ и даже больше) непрерывно на большой скорости, а далее работают уже на нормальной скорости. Вот для этого и нужен большой буфер.

[PavelPic]

jcxz, вам что нужно? Это моё личное дело как делать и как слушать. Если не нравится напишите какую микросхему взять, а не умничайте. И где я написал что 8 бит использую. Читайте внимательно мои сообщения и кто тему создал. Мы не одно лицо.

[roman.com]

На Атмеге? Серьёзно??? Думаете - она потянет TLS?

да ! хочу ! На Атмеге 328

никогда не делал TLS...

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


да.
в соседней теме писали на SD карту блоками по 512 байт без файловой системы.
но все таки использовать SD карту вместо ОЗУ это неправильно.
поэтому думаем где взять ОЗУ.

в Атмеге 328 = 2048 байт ОЗУ. хватит ли этого ?
ну... зависит от стабильности потока)) при стабильном потоке джиттер минимальный. поэтому думаю хватит))
но это не точно.)) надо смотреть... считать...

[uquote="jcxz",url="/forum/viewtopic.php?p=4739385#p4739385"]многие станции отдают поток очень неравномерно: могут несколько секунд гнать на скорости в несколько раз выше скорости аудио-потока, потом пауза и снова - следующая порция. Некоторые сначала (сразу после подключения) выплёвывают большой объём (до 1МБ и даже больше) непрерывно на большой скорости, а далее работают уже на нормальной скорости. Вот для этого и нужен большой буфер.[/uquote]
в TCP протоколе приёмник передаёт размер приёмного буфера.
согласно протоколу TCP если буфер приёмника переполняется то передача приостанавливается.
и хотя я терпеть не могу TCP протокол (я всё делаю на UDP) но правила есть правила.

а вот как это работает на практике... с интернет радио... по протоколу TCP... я ещё не проверял...

[jcxz]

[uquote="PavelPic",url="/forum/viewtopic.php?p=4739424#p4739424"]jcxz, вам что нужно? Это моё личное дело как делать и как слушать. Если не нравится напишите какую микросхему взять, а не умничайте.[/uquote]Зачем тогда написали в форум? В форум люди пишут когда хотят пообщаться по интересующей теме. Если "личное дело", так и не пишите сюда - оставьте при себе.
И не надо хамить. Вы влезли в чужую тему и ещё указываете - кому тут писать, кому не писать.
[uquote="PavelPic",url="/forum/viewtopic.php?p=4739424#p4739424"]И где я написал что 8 бит использую. Читайте внимательно мои сообщения и кто тему создал.[/uquote]Читайте внимательно в какую тему вы написали. И не надо писать в тему, к вам не относящуюся. Или хотя бы нужно сообщать - о чём идёт речь.

PS: Раз не приемлете никакую критику, то пилите свой деревянный велосипед с квадратными колёсами дальше сами.

Добавлено after 3 minutes 5 seconds:
[uquote="roman.com",url="/forum/viewtopic.php?p=4739429#p4739429"]в TCP протоколе приёмник передаёт размер приёмного буфера.
согласно протоколу TCP если буфер приёмника переполняется то передача приостанавливается.
и хотя я терпеть не могу TCP протокол (я всё делаю на UDP) но правила есть правила.
[/uquote]Объясните это прошивке ESP8266. Она ни про какие размеры буфера знать не желает и валит без остановки - всё что отдаёт сервер. Потому буфер и нужен. Что там у ТС - понятия не имею и, судя по всему, - и он тоже.

Добавлено after 2 minutes 55 seconds:
[uquote="roman.com",url="/forum/viewtopic.php?p=4739429#p4739429"]в соседней теме писали на SD карту блоками по 512 байт без файловой системы.[/uquote]Да, можно конечно и так. И трусы можно через голову одевать. Но зачем?
И время будет тратиться не на решение реальной задачи, а на героическую борьбу с трудностями, которые сам же и создал.
А проблем там будет ещё очень и очень много. Особенно - судя по уровню владения предметом автора (из первых сообщений ).
TLS то будет кратно сложнее элементарного HTTP-протокола, в котором автор плавает (вовсе не как рыба в воде ).

[PavelPic]

jcxz, напишите где людям внешнюю ОЗУ на 1 Мбайт взять, а не про будки и трусы. Прежде чем критиковать и умничать предложите альтернативу. Писаниной каждый дурак может заниматься, но ничего не предложить.

[jcxz]

[uquote="PavelPic",url="/forum/viewtopic.php?p=4739447#p4739447"]jcxz, напишите где людям внешнюю ОЗУ на 1 Мбайт взять[/uquote]Зачем на 1МБ? Почему не взять на несколько МБ? Последний раз покупал на али MT48LC16M16A2 на 32МБ всего за 0.55 центов вместе с доставкой.
В чём именно проблема? купить можно в тыще мест, любую, какая нравится.
Или лучше - купить сразу отладочную плату с уже впаянной SDRAM (в моём радио как раз такая).
Что-нить типа (с SDRAM): https://www.aliexpress.com/item/1005008064689025.html
хватит за глаза и ещё останется (и ОЗУ и быстродействия).

Если непременно чешется попаять, то можно последовательную SRAM по SPI подключить. Например: https://eu.mouser.com/ProductDetail/ISS ... OcVg%3D%3D
4МБ за всего 3 евро/шт. Но мороки в работе с ней будет больше, чем с параллельной SDRAM. Хотя и меньше, чем с SD-картой.

[roman.com]

[uquote="HardWareMan",url="/forum/viewtopic.php?p=4739196#p4739196"]roman.com, есть годнейшее кино про создание интернет-радиоприёмника на МК, причём с разбором принимаемого потока (в том числе и с разбором структуры и метаданных):
[/uquote]
так себе кино...

1. Проигрывание потока MP3 станции 320 кб/с, стерео, HTTP = до ~26%

конкретно у меня 192 кб/с

5-сервер передаёт плееру обычный HTTP ответ...

HTTP/1.0 200 OK
icy-br: 192
icy-pub: 1
icy-description: 1.FM - Radio Gaia
icy-url: http://1.fm
Instance-id: ab50168940339c8583715106639d847f
Cache-Control: no-cache
Server: AIS Streaming Server 8.6.5
icy-genre: Chill
Expires: Mon, 26 Jul 1997 05:00:00 GMT
icy-metaint: 8192
Pragma: no-cache
icy-name: 1.FM - Radio Gaia
Connection: close
Content-Type: audio/mpeg

итого
192000 б/с / 8 = 24000 байт в секунду.
потянет ли Ардуино ? думаю да))

на анализаторе видно что поток довольно равномерный.
это значит что большой буфер не требуется.
возможно он вообще не нужен))
[uquote="roman.com",url="/forum/viewtopic.php?p=4739429#p4739429"]думаем где взять ОЗУ.
в Атмеге 328 = 2048 байт ОЗУ. хватит ли этого ?[/uquote]
плюс 2048 байт ОЗУ в самой W5500.
а всего в самой W5500 16384 байт ОЗУ.
вот у нас уже есть целых 16 кбайт ОЗУ.
[uquote="jcxz",url="/forum/viewtopic.php?p=4739441#p4739441"][uquote="roman.com",url="/forum/viewtopic.php?p=4739429#p4739429"]в TCP протоколе приёмник передаёт размер приёмного буфера.
согласно протоколу TCP если буфер приёмника переполняется то передача приостанавливается.
и хотя я терпеть не могу TCP протокол (я всё делаю на UDP) но правила есть правила.
[/uquote]Объясните это прошивке ESP8266. Она ни про какие размеры буфера знать не желает и валит без остановки - всё что отдаёт сервер. Потому буфер и нужен.[/uquote]
значит это дуратская прошивка.
в нормальной прошивке размер приёмного буфера можно настраивать.
пишут что в ESP8266 RAM 82 kB (доступно около 52 kB). не знаю.
но мы я так понял будем делать на W5500. поэтому у нас есть 16384 байт ОЗУ.

но на самый главный вопрос...
[uquote="roman.com",url="/forum/viewtopic.php?p=4739429#p4739429"]и хотя сам принцип работы TLS мы уже разбирали... но сами библиотеки TLS я ещё не писал...
у кого есть опыт... поделитесь))[/uquote]
ответ не услышали))

на видео выше использовали MP3 декодер на VS1053.
поэтому второй логичный вопрос - а кто писал свою библиотеку MP3 декодера ?

[PavelPic]

Я писал для VS1053B и VS1063A. Настройка регистров и далее передача аудио потока.

[jcxz]

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]конкретно у меня 192 кб/с[/uquote]Из чего сделано такое умозаключение?

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]192000 б/с / 8 = 24000 байт в секунду.
потянет ли Ардуино ? думаю да))[/uquote]Однозначно - нет. Достаточно взглянуть на значения загрузки CPU, которые я приводил.

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]на анализаторе видно что поток довольно равномерный.
это значит что большой буфер не требуется.[/uquote]Это примерно как: шагнул один шаг по минному полю - и... "о! повезло, не рвануло под ногами, значит можно и дальше ходить безопасно".
Попробуйте ещё хотя-бы несколько сотен других станций перебрать, как сделал я, а только потом пытаться делать выводы.

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"][uquote="jcxz",url="/forum/viewtopic.php?p=4739441#p4739441"]Объясните это прошивке ESP8266. Она ни про какие размеры буфера знать не желает и валит без остановки - всё что отдаёт сервер. Потому буфер и нужен.[/uquote]
значит это дуратская прошивка.[/uquote]Это официальная прошивка. И другой нет. Если знаете - посоветуйте другую, "недуратскую", которая позволяет задать размер TCP-окна?

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]в нормальной прошивке размер приёмного буфера можно настраивать.[/uquote]Ссылку на "нормальную прошивку" (и документацию к ней) - в студию!

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]но на самый главный вопрос... ответ не услышали))[/uquote]Какой ответ и на какой вопрос вы ожидаете?

[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]но мы я так понял будем делать на W5500. поэтому у нас есть 16384 байт ОЗУ.[/uquote]Один AES-кадр может весить 16KB. Как вы его собрались дешифровывать, если даже скачать некуда?
Это уж не говоря о буфере аудио-декодера, буфере сэмплов ЦАП и т.д.

[roman.com]

Из чего сделано такое умозаключение?

из картинки...

Однозначно - нет. Достаточно взглянуть на значения загрузки CPU, которые я приводил.

загрузки какого CPU ?

На Атмеге? Серьёзно??? Думаете - она потянет TLS?
Чтобы примерно представляли о чём идёт речь - загрузка CPU в моём радио:

1. Проигрывание потока MP3 станции 320 кб/с, стерео, HTTP = до ~26% http://icecast.vgtrk.cdnvideo.ru/vestifm
2. Проигрывание потока AAC станции 160 кб/с, стерео, HTTP = до ~27% http://lr4mp1.latvijasradio.lv:8018
3. Проигрывание потока AAC+ станции 48 кб/с, стерео, HTTP = до ~48% http://stream.grad-petrov.ru:8093/aac
4. Проигрывание потока AAC+ станции 96 кб/с, моно, HTTPS = до ~34% https://live.radiospinner.com/etkvkz-96
5. Проигрывание потока MP3 станции 256 кб/с, стерео, HTTPS = до ~32% https://stream.cassiopeia-station.ru:5125/stream
Самый тяжёлый вариант был бы на высоких скоростях для AAC+, стерео, HTTPS. Но станция AAC+, стерео, 128кб/с, HTTPS, которую раньше использовал для тестов, сейчас не работает. Раньше на ней загрузка CPU была 70...80%. Другую аналогичную, но работающую - к сожалению не знаю.

Это на Cortex-M4F с тактовой = 96МГц и с буферами в SDRAM.
Загрузка - суммарная: скачивание (WiFi через ESP8266), TLS (soft AES), декодирование аудио (Helix), обновление бегущей картинки на LCD 320x240, и много другой мелочи.
Загрузка CPU на HTTPS очень сильно зависит от размеров кусков кодирования потока: при больших кусках (по неск. КБ) загрузка сильно прыгает, при мелких кусках - более равномерная. Также многие станции отдают поток очень неравномерно: могут несколько секунд гнать на скорости в несколько раз выше скорости аудио-потока, потом пауза и снова - следующая порция. Некоторые сначала (сразу после подключения) выплёвывают большой объём (до 1МБ и даже больше) непрерывно на большой скорости, а далее работают уже на нормальной скорости. Вот для этого и нужен большой буфер.

о каком CPU тут идёт речь ?
Cortex-M4F с тактовой = 96МГц ?
ESP8266 ?

у нас нет ни Cortex-M4F (с тактовой = 96МГц), ни ESP8266.
у нас есть Ардуино (с тактовой = 16МГц, максимум = 20МГц).
покажите загрузку CPU Ардуино (с тактовой = 16МГц, максимум = 20МГц).

Это официальная прошивка. И другой нет. Если знаете - посоветуйте другую, "недуратскую", которая позволяет задать размер TCP-окна?

у нас нет ESP8266.

Какой ответ и на какой вопрос вы ожидаете?

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

Один AES-кадр может весить 16KB. Как вы его собрались дешифровывать, если даже скачать некуда?

о каком AES-кадре идёт речь ?
согласно стандарту AES шифрует блоками по 16 байт.

Это уж не говоря о буфере аудио-декодера, буфере сэмплов ЦАП и т.д.

я не знаю ничего о буфере аудио-декодера, буфере сэмплов ЦАП...
до этого мы ещё не дошли))

но сначала разберёмся с потоками...

1.
на видео выше говорится про "методанные"...
да.

сервер передаёт плееру обычный HTTP ответ...

HTTP/1.0 200 OK
icy-br: 192
icy-pub: 1
icy-description: 1.FM - Radio Gaia
icy-url: http://1.fm
Instance-id: ab50168940339c8583715106639d847f
Cache-Control: no-cache
Server: AIS Streaming Server 8.6.5
icy-genre: Chill
Expires: Mon, 26 Jul 1997 05:00:00 GMT
[img]icy-metaint:%208192[/img]
Pragma: no-cache
icy-name: 1.FM - Radio Gaia
Connection: close
Content-Type: audio/mpeg

icy-metaint: 8192 это и есть "методанные"...
получается что в данном случае сервер передаёт поток блоками по 8192 байт.
к сожалению подробно рассмотреть "методанные" не могу... ссылка больше не работает))

2.
тогда откроем другую ссылку...

HTTP.jpg

(218.33 КБ) 331 скачивание

сервер передаёт плееру обычный HTTP ответ...

HTTP/1.0 200 OK
Server: Vmeste v1.6
Date: Mon, 18 Aug 2025 09:30:33 GMT
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
Access-Control-Allow-Headers: Origin, Accept, Content-Type, X-Requested-With
Content-Type: audio/mpeg
icy-br: 128
icy-name: LOVE IS RADIO
icy-djname: LOVE IS RADIO
icy-description: LOVE IS RADIO
icy-url: https://loveisradio.by
icy-pro: 1

никаких "методанные" тут нет...
получается что в данном случае сервер передаёт просто поток... непрерывный поток байт.

3.
в следующем пакете уже идёт сам поток MP3... непрерывный поток байт.

MP3.jpg

(209.54 КБ) 129 скачиваний

вначале идёт заголовок (ff)... тип файла(fb)...


получается что на видео выше нас обманули))
никаких "методанные" тут нет...
получается что не все сервера передают "методанные"...
[uquote="roman.com",url="/forum/viewtopic.php?p=4739429#p4739429"][uquote="jcxz",url="/forum/viewtopic.php?p=4739385#p4739385"]многие станции отдают поток очень неравномерно: могут несколько секунд гнать на скорости в несколько раз выше скорости аудио-потока, потом пауза и снова - следующая порция. Некоторые сначала (сразу после подключения) выплёвывают большой объём (до 1МБ и даже больше) непрерывно на большой скорости, а далее работают уже на нормальной скорости. Вот для этого и нужен большой буфер.[/uquote]
в TCP протоколе приёмник передаёт размер приёмного буфера.
согласно протоколу TCP если буфер приёмника переполняется то передача приостанавливается.
и хотя я терпеть не могу TCP протокол (я всё делаю на UDP) но правила есть правила.

а вот как это работает на практике... с интернет радио... по протоколу TCP... я ещё не проверял...[/uquote]
тогда смотрим как это на практике...

1.
приёмник передаёт серверу размер своего буфера.
в какой то момент буфер приёмника переполняется...
в данном случае размер буфера приёмника сократился до 488 байт.

size 488.jpg

(155.07 КБ) 799 скачиваний

сервер хочет передать следующий пакет... но не может))
поэтому сервер передаёт пакет... Window Full ))

Window Full.jpg

(163.68 КБ) 125 скачиваний

приёмник подтверждает что буфер приёмника переполнился... и следующий пакет принять не может))

Zero Window.jpg

(159.22 КБ) 125 скачиваний

в этом случае передача приостанавливается...
2.
после очистки буфера приёмника передача возобновляется...

да. именно так и работает протокол TCP.
и хотя я терпеть не могу TCP протокол... но это уже другая история))

с этим разобрались.
[uquote="jcxz",url="/forum/viewtopic.php?p=4739385#p4739385"]Также многие станции отдают поток очень неравномерно: могут несколько секунд гнать на скорости в несколько раз выше скорости аудио-потока, потом пауза и снова - следующая порция. Некоторые сначала (сразу после подключения) выплёвывают большой объём (до 1МБ и даже больше) непрерывно на большой скорости, а далее работают уже на нормальной скорости. Вот для этого и нужен большой буфер.[/uquote]
а почему такое может быть ?
ну... причины могут быть разные))
- большая нагрузка на севрер.
- плохая связь с сервером.
- другое))

проверим связь.
тестовая программа показывает нам как работает связь по 3G...

видно что поток не равномерный... это плохая связь с тестовым сервером.
в динамике слышно как "булькает" и "заикается"...))

для сравнения так работает связь по Wi-Fi...

видно что поток равномерный... это хорошая связь с тестовым сервером.
в динамике ничего не "булькает" и не "заикается"...))

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

пакеты.jpg

(230.51 КБ) 139 скачиваний

видно что поток равномерный... это хорошая связь с радио сервером.
в динамике ничего не "булькает" и не "заикается"...))

вывод: надо делать интернет радио работающего по оптике.))

далее...
[uquote="roman.com",url="/forum/viewtopic.php?p=4739526#p4739526"]итого
192000 б/с / 8 = 24000 байт в секунду.
потянет ли Ардуино ? думаю да))[/uquote]
в нашем примере сервер передаёт со скоростью 128 кбит/c.

смотрим...

байты.jpg

(149.85 КБ) 138 скачиваний

в среднем 15 пакетов в секунду... в каждом пакете в среднем 1460 байт...

на первой секунде...
получается 141486 - 123617 = 17869 байт в секунду... или 142952 бит в секунду...

на второй секунде...
13897 байт в секунду... или 111176 бит в секунду...

и т.д.
в среднем получаем 16000 байт в секунду... или 128 кбит/c...

сможет ли ардуино принят 15 пакетов в секунду ?
да, вполне))

в прошлой теме мы делали "сервер"))
W5500_client+Atmega8 = "сервер"))

и начали загружать на наш "сервер" всё подряд...

картинки...


музыку... MP3...


и даже видео... MP4...


при этом скорость загрузки составила 6...7 мс на пакет или 140 пакетов в секунду... или более 1 Мбит в секунду ! ))
~1,5 Мбит в секунду.
при этом Ардуина даже не старалась... работала от RC-генератора = 8 Мгц. ))

а вы говорите невозможно.
с Ардуино всё возможно ! ))

правда в последнем примере это был просто тест скорости...
но нам ещё надо куда то дальше передавать поток... на VS1053B или VS1063A.
ну тогда (грубо) поделите скорость на двое ))
[uquote="jcxz",url="/forum/viewtopic.php?p=4739385#p4739385"][uquote="PavelPic",url="/forum/viewtopic.php?p=4739326#p4739326"]Про поддержку HTTPS согласен. Я только начал библиотеку писать для интернет радио, со временем добавлю когда жизнь заставит.[/uquote]На Атмеге? Серьёзно??? Думаете - она потянет TLS?[/uquote]
я бы не спешил с выводами... ))


так всё таки... где наши "методанные"... ???

подключимся к другому серверу...

HTTP.jpg

(173.67 КБ) 326 скачиваний

HTTP/1.0 200 OK
icy-notice1:
This stream requires <a href="http://www.winamp.com">Winamp
icy-notice2:SHOUTcast DNAS/posix(bsd) v2.4.7.256
icy-name:Rewound Radio
icy-genre:Oldies
icy-br:64
icy-url:http://rewoundradio.com
icy-pub:1
content-type:audio/mpeg
icy-metaint:32768
X-Clacks-Overhead:GNU Terry Pratchett....

icy-metaint: 32768 это и есть "методанные"...
получается что в данном случае сервер передаёт поток блоками по 32768 байт.

переходим на 32768 байт...

метаданные.jpg

(186.12 КБ) 342 скачивания

вот они ! ))


а если подключатся браузером... то...

HTTP/1.0 200 OK
icy-notice1:
This stream requires <a href="http://www.winamp.com">Winamp
icy-notice2:SHOUTcast DNAS/posix(bsd) v2.4.7.256
icy-name:Rewound Radio
icy-genre:Oldies
icy-br:64
icy-url:http://rewoundradio.com
icy-pub:1
content-type:audio/mpeg
X-Clacks-Overhead:GNU Terry Pratchett....

"методанные"... нет.

пипец)) это ещё и от клиента зависит...
как у вас всё запущенно))

далее...
а где наш TLS ? ))

для начала вспомним как работает TLS... на примере телеграмм))
подключаемся...

выбираем ближайший сервер...
Telegram_Messenger_Network
149.154.167.99

предлагаем на выбор шифрование...
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
...

выбираем последний (самый свежий)... TLS_AES_256_GCM_SHA384
дальше всё стандартно... обмен ключами... сессии... и т.д.

загрузим что-нить на сервер Telegram... скачаем что-нить... нас интересует звук...

всё ясно))

далее TLS_AES_256_GCM_SHA384

делаем AES_256 в режиме GCM... на Ардуино))

режим GCM выглядит так...



берём ардуино мега8 и для начала сделаем AES_128...



получили скорость шифрования/расшифрования 1000 байт в секунду...



но нам надо AES_256... поэтому переделываем...



получили скорость шифрования/расшифрования 700 байт в секунду...
да. на мега8 AES_256 прекрасно работает. только память закончилась))
поэтому берём мегу328. на ней AES_256 работает идеально.))

при тактовой = 16 МГц в среднем получаем шифрования/расшифрования 1600 байт в секунду... или 12 кбит/c...
но нам надо минимум 16000 байт в секунду... или 128 кбит/c...
думаем))
-можно оптимизировать программу.
-можно распараллелить процесс... на несколько ардуин)) к счастью режим GCM это потоковый шифр. ))


ну и осталось добавить RSA.
Протокол Ди́ффи-Хе́ллмана на эллиптических кривых (ECDH).
для этого надо найти где-то ещё несколько килобайт памяти))

SHA384 наверное делать не будем... открытый текст передавать не будем))
даже сертификаты проверять не будем...
наше дело подключиться к серверу... обменяться ключами... получить и расшифровать поток...
всё))

TLS 1.3 уже почти готов))

[roman.com]

радио... радио...
а давайте сделаем IP телефон ! )) или интернет-рацию... кому как больше нравится.
скоро все мессенджеры заблокируют... будем звонить по телефону.))



для этого берём:
- старый телефон.
- W5500 + Atmega8.



передатчик:

сначала попробуем передать звук с ардуины на комп...
подключаем W5500 к компу...
нажимаем на ардуине кнопочку "тест"... побежали пакетики))



работает))

посчитаем примерно скорость передачи по интернету:
~680 пак/сек * 32 байт/пакет * 8 бит/байт = ~400 кбит/с... при частоте МК 8 мгц...
значит ардуина будет передавать по интернету со скоростью примерно до 1 Мбит/c.
нормально))
можно ещё чуть- чуть поднять скорость... но думаю для звука ~1 Мбит/c пока достаточно.

смотрим:



скорость передачи: 8000 (байт/с) / 512 (байт/пак) = 15,625 (пак/с)...
замечательно)) поток стабильный.
видим небольшой фон... ))



подключаем микрофон...
видим большой фон... ))



чувствительность АЦП высокая...

1. из-за высокой чувствительности АЦП очень много шума...
2. из-за выбега частоты постоянный треск)) стабильность частоты RC-генератора МК оставляет желать лучшего)) что было ожидаемо... нужен кварц.

выводы:
схема рабочая.
но над качеством звука надо ещё поработать...


приёмник:

в Ардуино ЦАП нет... поэтому сделаем быстрый ШИМ...




Единственная проблема - ардуина не сможет шифровать трафик с такой скоростью. В остальном все решаемо.
Для шифрования думаю подойдёт ESP32. Но это уже другая история))

[kondeg]

Всем доброго здоровья и особенно Роману roman.com,
Прошло уже 4 года с первых сообщений в этой ветки форума и хочется поделится мнением.
В стране многое изменилось, мы (наверное) тоже изменились.
Но W5500_client+Atmega8 все это время работает, и довольно таки стабильно. Не сказать конечно, что эта связка перегружается объемом передаваемых данных, но все же. Каждые 30 секунд на сервер "улетают" данные температур. Несколько раз "оптимизировал" web_сайт (интереса ради начал вести статистику ip посещений, выявлять уникальные(новые ip) за день и чаще всего встречающийся ip за месяц (понимаю, что попадаются широковещательные запросы) но все же).
Вот как то так...
Всем мирного неба над головой. Особенно сейчас это стало актуально.

[roman.com]

Мы не изменились. Обстановка изменилась.
С учётом новой обстановки сервер должен быть с шифрованием.
Чтобы противник не смог нас подслушать)).


к слову... а мы подробно разобрали работу роутера ?

1.png

(151.06 КБ) 137 скачиваний

что-то я не помню... роутер проверяет IP отправителя из WAN или нет...

есть мысля сделать STUN.

[roman.com]

что-то я не помню... роутер проверяет IP отправителя из WAN или нет...

судя по всему... да.
изменил IP пакета на другой... и роутер пакет не пропустил.
значит STUN не получится.
жаль))

[PavelPic]

Закончил разбираться с интернет радио. Буфер, который я задействовал 512 байт внутреннего ОЗУ микроконтроллера, а не 32 Гбайт SD карты или 1 Мбайт внешнего ОЗУ. И то 512 байт требуется, если битрейт более 128 к/бит в секунду. Оказалось, чтобы не заикалось надо ставить буфер W5500 4 килобайта, каждые 100 мс проверять, сколько новых байт в буфере, если более 256 байт или 512 байт, то передавать их в VS1063A. Затем записывать в W5500, сколько байт было считано, так как размер принятых данных (0x0026 0x0027) - есть разность между значениями регистров 0x002a 0x002b и 0x0028 0x0029. И так по кругу по истечению 60..80 мс. Остальные 20..40 мс на выполнение другой программы. Если буфер W5500 более 4 килобайт или менее 4 килобайт, то происходит процесс заикания. Видимо, зависит от битрейта.
При этом станции, где указан только IP адрес без порта (ставил порт 80) заикаются при любом буфере W5500. С чем связано не известно. При использовании сетевого моста между USB 4G модемом и сетевой картой, к которой подключена W5500, в диспетчере задач можно смотреть скорость передачи в W5500.

[jcxz]

[uquote="PavelPic",url="/forum/viewtopic.php?p=4742213#p4742213"]При этом станции, где указан только IP адрес без порта (ставил порт 80) заикаются при любом буфере W5500. С чем связано не известно.[/uquote]С маленьким буфером связано, кэп.

[roman.com]

1.
буфер приёмника может быть ни причём.
-если буфер приёмника переполняется то поток буферизируется в передатчике.
по крайне мере так работает тсп протокол. (см. выше).
а вот какой там буфер в передатчике... зависит от настроек сервера... я не проверял... но можно проверить.

2.
передайте MP3 из ПК на свой приёмник... для проверки))

3.
для ускорения работы я использую прерывания в мк.
вывод INT модуля W5500 подключаю к INT прерывания МК.
скорость при этом максимальная. несколько Мбит/с.

4.
какой буфер у VS1063A я не знаю. надо смотреть даташит.
5.
всё надо смотреть в анализаторе... тогда всё будет ясно. где слабое место и что делать дальше))

[jcxz]

[uquote="roman.com",url="/forum/viewtopic.php?p=4742284#p4742284"]1.
буфер приёмника может быть ни причём.
-если буфер приёмника переполняется то поток буферизируется в передатчике.[/uquote]С чего вы взяли, что проблемы из-за "переполнения в передатчике"?
Скорее всего проблемы будут не из-за overflow, а из-за underflow. В приёмнике. Когда все данные уже отправлены в декодер, а новых ещё почему-то нет. Элементарный расчёт показывает на сколько хватит буфера 4KB (для произвольного потока): 4096*8/320000 = ~0.1 сек
Надеяться на то, что интернет-соединение настолько стабильно, что не допускает задержек/замираний даже на несколько десятков мсек - это надо быть ОЧЕНЬ БОЛЬШИМ оптимистом!

Да и не факт, что все сервера трансляций настолько стабильно транслируют контент, что прям аж до десятков мсек стабильно. И при том, что у такого сервера может быть множество (сотни/тысячи?) одновременно открытых TCP-соединений. И каждому нужно успеть отгрузить свою порцию байт. В таком случае серверу оптимальнее отгружать в каждый TCP-сокет данные большими порциями, а не мелкими кусками.
Уже не говоря о случае, когда используется TSL.
Я уже писал выше, что тестил сотни разных интернет-вещателей. Со стабильностью потока у многих всё очень плохо.

Добавлено after 3 minutes 14 seconds:
[uquote="PavelPic",url="/forum/viewtopic.php?p=4742213#p4742213"]Если буфер W5500 более 4 килобайт или менее 4 килобайт, то происходит процесс заикания.[/uquote]А это говорит о том, что скорее всего и другие баги в коде имеются. Раз "шаг влево, шаг вправо" - уже глючит.

[roman.com]

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

Передатчик не может передать больше чем может принять приёмник. Так работает протокол тсп.
Если приемник не может принять поток то в этом случае у передатчика два выхода:
-буферизировать поток в передатчике и ждать когда приемник будет готов принять поток. При этом булькать не будет.
-отбросить байты потока... и передавать дальше. В этом случае будеть булькать.

Выше я передавал поток с ПК на W5500.
Там поток стабильный с точностью до несколько миллисекунд благодаря тому что сам протокол тсп стабилизировался поток.

Короче надо смотреть анализатор.

[jcxz]

[uquote="roman.com",url="/forum/viewtopic.php?p=4742312#p4742312"]Я не говорил что проблема в буфере передатчика. Я сказал что проблема может быть в другом. Вообще не в буферах.[/uquote]Это всегда возможно.

[uquote="roman.com",url="/forum/viewtopic.php?p=4742312#p4742312"]Если приемник не может принять поток то в этом случае у передатчика два выхода:
-буферизировать поток в передатчике и ждать когда приемник будет готов принять поток. При этом булькать не будет.[/uquote]Булькать будет и в этом случае. Ведь булькает не передатчик, а MP3-декодер, которому не хватает данных. Он ведь не может сказать динамику "Потерпи дружище, не булькай, мне пока от TCP новые данные не пришли".