• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Обсуждение Интернет радио на 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
 

sir66

New member
Интересный проект. А можно подробгне про схему фильтра. В чем ее смысл?
 

samand587

New member
Стал обладателем "ESPmini DAC". К сожалению автор не ведет техническую поддержку своего проекта. У меня нет звукового сопровождения вводимых команд, при попытке обновления через браузер идет сброс. Почему то не хотят работать пункты в разделе «Обновление через WEB интерфейс» статьи. Сбрасывается загрузка браузера. И канал №6 не записывает радиостанцию. Автор на мои вопросы не ответил! Жаль!
 

enjoynering

Well-known member
зачем вы покупаете этот проект с закрытым исходным кодом? есть же ka-radio32 на esp32 и даже ka-radio на esp8266. там можно прикрутить VS1053 - аппаратный кодек flac, mp3, ogg и aac c DSP, у которого звук на много лучше чем встроенный DAC у esp32.
 

Alcest

Member
Если все закрыто и запаролено, этогда это должен быть не "прАЭкт", а готовое к использованию устройство. Полностью готовое, в корпусе с кнопочками и лампочками, и с инструкцией пользователя.
 
Сверху Снизу