ОЗУ - это устройство с произвольным доступом. И на порядки более быстрым, чем SD. Ваша затея напоминает, как если бы кто-то хотел себе дом, и потому купил собачью конуру и затем при помощи напильника пытался доработать её до полноценного дома. Зачем? Каждая задача требует адекватных инструментов для своего решения.
Т.е. - вы создаёте такое радио, которое надо будет включать по расписанию? А если случайно заснул и забыл выключить - наутро нужно искать новую SD-карту???
Радио - это такая вещь, которую включил и оно играет и играет, фоном. Если ещё и думать - сколько оно там по таймеру поиграло, чтобы вовремя выключать??.. ну нафиг такое "радио"!...
На Атмеге? Серьёзно??? Думаете - она потянет 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МБ и даже больше) непрерывно на большой скорости, а далее работают уже на нормальной скорости. Вот для этого и нужен большой буфер.

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

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

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

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


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

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


в TCP протоколе приёмник передаёт размер приёмного буфера.
согласно протоколу TCP если буфер приёмника переполняется то передача приостанавливается.
и хотя я терпеть не могу TCP протокол (я всё делаю на UDP) но правила есть правила.

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

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

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

Добавлено after 3 minutes 5 seconds:
Объясните это прошивке ESP8266. Она ни про какие размеры буфера знать не желает и валит без остановки - всё что отдаёт сервер. Потому буфер и нужен. Что там у ТС - понятия не имею и, судя по всему, - и он тоже.

Добавлено after 2 minutes 55 seconds:
Да, можно конечно и так. И трусы можно через голову одевать. Но зачем?
И время будет тратиться не на решение реальной задачи, а на героическую борьбу с трудностями, которые сам же и создал.
А проблем там будет ещё очень и очень много. Особенно - судя по уровню владения предметом автора (из первых сообщений ).
TLS то будет кратно сложнее элементарного HTTP-протокола, в котором автор плавает (вовсе не как рыба в воде ).

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

Зачем на 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-картой.

так себе кино...

конкретно у меня 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 байт в секунду.
потянет ли Ардуино ? думаю да))

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

плюс 2048 байт ОЗУ в самой W5500.
а всего в самой W5500 16384 байт ОЗУ.
вот у нас уже есть целых 16 кбайт ОЗУ.

значит это дуратская прошивка.
в нормальной прошивке размер приёмного буфера можно настраивать.
пишут что в ESP8266 RAM 82 kB (доступно около 52 kB). не знаю.
но мы я так понял будем делать на W5500. поэтому у нас есть 16384 байт ОЗУ.

но на самый главный вопрос...

ответ не услышали))

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

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

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

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

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

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

Ссылку на "нормальную прошивку" (и документацию к ней) - в студию!

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

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

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


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

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

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

у нас нет ESP8266.

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

о каком 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 ответ...

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... непрерывный поток байт.

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


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

тогда смотрим как это на практике...

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

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

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

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

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

с этим разобрались.

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

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

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

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

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

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

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

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

далее...

в нашем примере сервер передаёт со скоростью 128 кбит/c.

смотрим...

в среднем 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.
ну тогда (грубо) поделите скорость на двое ))

я бы не спешил с выводами... ))


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

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

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 байт...

вот они ! ))


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

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 уже почти готов))

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



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



передатчик:

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



работает))

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

смотрим:



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



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



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

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

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


приёмник:

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




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

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

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


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

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

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

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

Закончил разбираться с интернет радио. Буфер, который я задействовал 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.

С маленьким буфером связано, кэп.

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

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

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

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

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

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

Добавлено after 3 minutes 14 seconds:
А это говорит о том, что скорее всего и другие баги в коде имеются. Раз "шаг влево, шаг вправо" - уже глючит.

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

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

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

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

Это всегда возможно.

Булькать будет и в этом случае. Ведь булькает не передатчик, а MP3-декодер, которому не хватает данных. Он ведь не может сказать динамику "Потерпи дружище, не булькай, мне пока от TCP новые данные не пришли".