Обсуждение Интернет радио на ESP32

Интересен ли вам данный проект?

  • Да

  • Нет


Результаты будут видны только после голосования.

pvvx

Активный участник сообщества
опять Вы не угадали.
Напрасно пытаетесь угадывать что делали другие. Это занятие бесполезное и увлекает лишь вас.
Рассуждайте о том, что делали сами.
В интернет радио-трансляции необходимо четко поддерживать скорость вывода разжатых данных. Если у вас задающий кварц DAC уходит в плюс, то канал трансляции в скором времени, при опережении вывода, вам не даст данные – будет дырка. Если кварц уходит в минус, то сервер, при наборе определенной длины буферизации вашего соединения прекратит буферизировать данные для вас, и в зависимости от реализации прервет поток или нелепо соединит его с текущим, удалив буфер –> будет перескок и кусок трансляции выпадет. Чтобы этого не происходило, подстраивают частоту вывода по реакции сервера – всегда запрашивают данные в буфер вперед, а сервер, выдав предбуфер, далее отдает их со своей скоростью, к которой вы должны синхронизоваться, фильтруя сетевые биения... :p
Так наверно 'Гуру' будет понятней ? :)
При этом сервер ну ни как не гарантирует, что его скорость вывода потока трансляции синхронизирована с цезиевыми часами. :) -> Говорить о реал-тайм возможно исключительно с массой поправок... Как синхронизовать ваш вывод с потоком от сервера - путем аналогового ФАПЧ (PLL) или путем примитивного удаления или вставки N-ного отсчета вывода в DAC (алго дешевки ESP8266/ESP32) - это ваше право и влияет на качество выводимого звука. :p Без этого обязательно будут дырки или "крякания" ... :)
 
Последнее редактирование:

Alcest

Member
Решается элементарно. Открывается и минимально буферизируется N каналов в плюс и N каналов в минус от текущего проигрываемого по индексу списка выбора. Т.е. в DAC проигрывается текущий канал, а другие 2N буферизируются и проигрываются в никуда.
Я думал о таком варианте, но почему-то решил, что потребуются 3 штуки ESP32 на каждом из которых крутиться по проигрывателю потокового звука. 1 работает, 2 ждут и начинают воспроизводить в зависимости от направления вращения энкодера. Понятно, что я сразу же отбросил идею с нагромождением модулей, а то, что один модуль справится с тремя потоками сразу мне в голову не пришло. Наверное потому, что я еще не в курсе всех возможностей ESP32.
С онлайн-радио никакие ручки настроек крутить не надо.
Надо. Вращение ручки - самый удобный способ переключения чего либо, в том числе и потоков в интернет-радио.
 
Последнее редактирование:

rst

Member
Чтобы этого не происходило, подстраивают частоту вывода по реакции сервера – всегда запрашивают данные в буфер вперед, а сервер, выдав предбуфер, далее отдает их со своей скоростью, к которой вы должны синхронизоваться, фильтруя сетевые биения... :p
Так наверно 'Гуру' будет понятней ? :)
Я думаю - это стало откровением для "Мега-гуру" :D
 

nikolz

Well-known member
В интернет радио-трансляции необходимо четко поддерживать скорость вывода разжатых данных. Если у вас задающий кварц DAC уходит в плюс, то канал трансляции в скором времени, при опережении вывода, вам не даст данные – будет дырка. Если кварц уходит в минус, то сервер, при наборе определенной длины буферизации вашего соединения прекратит буферизировать данные для вас, и в зависимости от реализации прервет поток или нелепо соединит его с текущим, удалив буфер –> будет перескок и кусок трансляции выпадет. Чтобы этого не происходило, подстраивают частоту вывода по реакции сервера – всегда запрашивают данные в буфер вперед, а сервер, выдав предбуфер, далее отдает их со своей скоростью, к которой вы должны синхронизоваться, фильтруя сетевые биения... :p
Так наверно 'Гуру' будет понятней ? :)
При этом сервер ну ни как не гарантирует, что его скорость вывода потока трансляции синхронизирована с цезиевыми часами. :) -> Говорить о реал-тайм возможно исключительно с массой поправок... Как синхронизовать ваш вывод с потоком от сервера - путем аналогового ФАПЧ (PLL) или путем примитивного удаления или вставки N-ного отсчета вывода в DAC (алго дешевки ESP8266/ESP32) - это ваше право и влияет на качество выводимого звука. :p Без этого обязательно будут дырки или "крякания" ... :)
я тоже рад Вас слышать.
Не выдержали?
Вы как обычно все написали правильно но не про то что я сказал.
Частота кварца не есть частота вывода данных Это Вы знаете.
Я написал про частоту квантования данных на входе и данных на выходе
данные на выходе в идеале квантуются с частотой квантования аналогового сигнала от первичного источника Для этого сигнал и восстанавливается.
Если бы скорость поступления данных на входе была бы равна скорости на выходе то применять алгоритмы сжатия не было бы смысла.
А применяют
Именно поэтому скорость на входе меньше или равна. Равна она будет лишь в моменты когда сжатие фактически ничего не дает.
Что скажите?
 

Alcest

Member
Это кому как. Только я сомневаюсь, что Вы сможете за 0.3-0.5 сек оценить - то что нужно играет или нет.
Минимальное время до появления звука в динамической головке нужно не для оценки контента, а для того чтобы при вращении энкодера "на слух" станции не проскакивать. Иначе можно энкодером весь плей-лист прокрутить от начала до конца и ничего не услышать. "Шелчки" энкодера даже при неспешном его вращении будут следовать быстрее, чем происходит буферизация потоков и выдача их в ЦАП.

Навскидку, ESP32 сможет буферизировать сразу 3 потока, одновременно воспроизводя один из этих трех? Справится, производительности хватит?
 

rst

Member
Минимальное время до появления звука в динамической головке нужно не для оценки контента, а для того чтобы при вращении энкодера "на слух" станции не проскакивать. Иначе можно энкодером весь плей-лист прокрутить от начала до конца и ничего не услышать.
Для обратной связи по положению в списке станций имеется LCD. По нему удобнее наблюдать прокручивание списка чем на слух.
Если будете пытаться на слух - всё равно будете проскакивать, так как в момент кручения могут быть паузы в звуковом потоке, а может сервер медленно данные выдавать, а может и коннект медленный быть. У меня вообще процесс кручения списка станций и процесс подключения/проигрывания/отключения - совершенно разные процессы. Первый процесс просто кладёт текущий URL (отображаемый сейчас на LCD) в поле запроса для второго процесса. А второй процесс, по мере освобождения, подключается к нему. Первый процесс никак не тормозится вторым, также как и второй - первым. Это независимые задачи.
Первый процесс - это графический интерфейс пользователя, осуществляющий интерактивное взаимодействие с юзером (отрисовку на LCD, обработка действий пользователя (нажатия, касания экрана и т.п)), а второй процесс - процесс работающий с серверами радиостанций (подключение, посылка/приём HTTP-запросов, приём/декодирование MPEG-потока, ресэмплинг и вывод потока сэмплов на ЦАП).
 
Последнее редактирование:

Alcest

Member
Для обратной связи по положению в списке станций имеется LCD. По нему удобнее наблюдать прокручивание списка чем на слух.
Конечно удобнее, если по другому уже никак и альтернативы никакой нет. А так нужно лишь поинтересоваться сколько эфирных цифровых DSP радиоприемников было разбито об угол и выброшено в мусорку только потому, что в них не было возможности настройки на слух из-за глубокого и продолжительного Soft-Mute, в отличие от старых аналоговых радиоприемников, где звук появлялся сразу после настройки на радиостанцию и можно было не высматривать частоту настройки на дисплее. Широкие массы считают возможность настраиваться не глядя на дисплей важной сервисной функцией радиоприемника, и не желают мириться с ее отсутствием.

Радио, это такая штука, которую часто используют тогда, когда глаза и руки заняты: во время работы, за рулем, на пробежке. И тут возможность просто протянуть руку и крутануть ручку не отвлекаясь от основного занятия дорогого стоит.
 

rv9c

New member
Здравствуйте. Пришли комплектующие для наборов. Кого интересуют комплекты для самостоятельной сборки обращайтесь на rv9c@yandex.ru

Евгений
ESPradio
 
Сверху Снизу