Перейти к содержанию
    

Микроконтроллер для Интернет радио

Задачу "internet radio" сделать можно на самом дохлом ARM7. Выбросить mp3 вместе с TCP, реализовать UDP/RTP и какой-нить простенький потоковый кодек типа G.711 и будет щастье.

 

С первой половиной утверждения вполне согласен. Со второй - нет. Ибо это будет узкозапиленное "радио".

 

Хотя я бы целил в AAC, битрейт заметно ниже. И самое главное. Некоторые тонкости протокола TCP позволяют не предъявлять особых требований к количеству ОЗУ, занимаемому под буфер потока на приемной стороне.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

О це что попалось на глаза

 

217044.jpg

 

The Internet Radio Demonstration Board uses the PIC18F67J60 8-bit microcontroller with integrated 10Base-T MAC and PHY to connect to SHOUTcast servers and stream MP3 data to an audio decoder. This demonstration board implements the basic features of an internet radio, such as volume control and station selection.

 

Features

PIC18F67J60 8-bit microcontroller with integrated 10Base-T MAC and PHY

Integrated magnetic RJ-45 connector with status LEDs

VLSI VS1011E MPEG Audio Codec to decode MP3 data streams and drive headphones

Two 256 Kbit serial SRAMs for buffering of TCP packets and MP3 audio data

Brilliant OLED display showing song title and author, station name and IP address of the demonstration board

Push button switches to control station, volume and bass

Connector for MPLAB® ICD 2 In-Circuit Debugger or MPLAB REAL ICE™ In-Circuit Emulator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что-то мне подсказывает, что звук от такого кодека будет наипоганейшим.. Так что "щастье" будет недолгим... :biggrin:

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

Дык, после того как запустится с простым кодеком, что мешает поменять кодек на более толстый?

 

 

И самое главное. Некоторые тонкости протокола TCP позволяют не предъявлять особых требований к количеству ОЗУ, занимаемому под буфер потока на приемной стороне.

Это интересно какие такие тонкости TCP позволят не предъявлять особых требования к количеству ОЗУ на покрытие сетевого джиттера?

 

При использовании TCP из плюсов имеем только:

- гарантированную доставку

 

из минусов:

- overhead данных

- необходимость отправки ACK'ов

- невозможность использования broadcast и multicast сессий

- потеря реалтайма

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это интересно какие такие тонкости TCP позволят не предъявлять особых требования к количеству ОЗУ на покрытие сетевого джиттера?

 

Дело в том, что всякие трансляторы типа ShowCast при трансляции через TCP автоматически поддерживают нужный для приемника битрейт. Это снимает вопросы пересемплирования на приемной стороне (эта обратная связь через размер окна поддерживается). Это раз. Вторая фича связанна с потоковым характером данных, что позволяет при наличии поддержки Fast Retransmit в TCP-стеке обойтись буферами всего размером в 4 сегмента передачи (которые есть смысл выбрать достаточно малыми, например, размером байт в 700). Ну и конечно поддержка Delayed Ack - тоже необходимое условие.

 

Наличие подтверждений каждого второго пакета практически не добавляет оверхеда.

 

И кстати, большинство радиостанций в большом интернете вещают именно через TCP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дык, после того как запустится с простым кодеком, что мешает поменять кодек на более толстый?

запас производительности. Например декодирование MPEG4 AAC (HEHQ профиль) 5.1 звука потребляет около 100 мегагерц C64+ ядра (вот по этим данным http://focus.ti.com/lit/ml/sprs369d/sprs369d.pdf, там Table 2). Простой арм7 вообще вымрет на этом. Ему дай бог справиться с самым простым тестом на LC. Ну а закладываться на внешний железячный кодек - это ограничить себя в возможности расширения функциональности продукта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот такое посмотреть не хотите: https://datatype.helixcommunity.org/2005/aacfixptdec

 

Нее..., тема кодеков для интернет радио можно сказать закрыта.

 

Но остро стоит тема подключения радиоприемников к интернету. Стоит крепко подумать о подключении через WiFi, WiMAX, 3G и т.д.

Здесь так скажем DSP и рядом не лежали.

 

запас производительности. Например декодирование MPEG4 AAC (HEHQ профиль) 5.1 звука потребляет около 100 мегагерц C64+ ядра (вот по этим данным http://focus.ti.com/lit/ml/sprs369d/sprs369d.pdf, там Table 2). Простой арм7 вообще вымрет на этом. Ему дай бог справиться с самым простым тестом на LC. Ну а закладываться на внешний железячный кодек - это ограничить себя в возможности расширения функциональности продукта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот такое посмотреть не хотите: https://datatype.helixcommunity.org/2005/aacfixptdec

И чего туда смотреть? 6 каналов @ 96 КГц зажрут ~300 МГц. А еще захочется записать это в реалтайме на SD-карточку в MP3-формате. Так что тема кодеков не закрыта. Если ARM не Cortex-A8 на гигагерце. Если топовый кортекс - полностью с Вами согласен, выбор вполне подходящий, не хуже DSP.

 

Но остро стоит тема подключения радиоприемников к интернету. Стоит крепко подумать о подключении через WiFi, WiMAX, 3G и т.д.

Здесь так скажем DSP и рядом не лежали.

И почему же они здесь не лежали? Вам религия не позволяет подключить WiFi-ник к DSP через mini-PCI (например), если надо? Мне лично позволяет. Прсото чип выбрать немного другой, с соотв. интерфейсом, и будет запас на расширение в этом направлении. Я при предложении исходил из интерфейса в вопросе автора. Я лично не вижу ни одной преграды для расширения и в этом направлении.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну в какой-то степени религия. :laughing: А что религия на пустом месте возникает?

Вот где вы взяли исходники или спецификацию хотя-бы чтобы подключить WiFi по мини PCI.

Народ с ног сбивается чтобы найти такую инфу, а у вас нет преград!?

Такие вещи обычно дают в виде скомпилированных драйверов и только под две всем известные операционки, которые уж точно не портируются на DSP, а вот в ARM за 10$ и TQFP корпусе лехко!

 

И почему же они здесь не лежали? Вам религия не позволяет подключить WiFi-ник к DSP через mini-PCI (например), если надо? Мне лично позволяет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот где вы взяли исходники или спецификацию хотя-бы чтобы подключить WiFi по мини PCI.

Например проект DD-WRT, опенсурсный линукс под разномастные вайфайные маршрутизаторы. И это не единственное место добычи исходников для работы с мини-писиайными вайфайниками. Это касается исходников. Из них нижний уровень выдрать, а верхние они те же, что и для Eth. А документация - для ее получения, как правило, ничего кроме NDA производители этих штуковин (PCI-ных чипов) не требуют, т.е. преград нет, кроме предубеждения у некоторых против того, что NDA это нечто заоблачно-замудреное. Я же после опыта работы с фабами в части заказных ИМС к таким некоторым не отношусь. Что касается собрать - то компиляторы 6000-ные поддерживают немало gcc-шных расширений, в общим портирование проходит не напряжно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дело в том, что всякие трансляторы типа ShowCast при трансляции через TCP автоматически поддерживают нужный для приемника битрейт. Это снимает вопросы пересемплирования на приемной стороне (эта обратная связь через размер окна поддерживается). Это раз. Вторая фича связанна с потоковым характером данных, что позволяет при наличии поддержки Fast Retransmit в TCP-стеке обойтись буферами всего размером в 4 сегмента

RTP работает с media frame'ами. В случае трансляции радио - буфер привязывается не к некому сегменту, а к аудио фреймам, точнее к их времени. Т.е. если в TCP буфер измеряется в символах, то в RTP - в секундах(милисекундах). RTP - это протокол специально предназначенный для передачи media потоков. Автоматическая смена битрейта (для кодеков которые поддерживают разный битрейт) предусматривается стандартом. Это протоколы разных уровней, т.к. никто не мешает пользовать RTP over TCP.

 

TCP это голый транспорт, самостоятельно без надстроек он не пригоден для решения поставленной задачи впринципе, точно также как RTP не сможет существовать без udp/tcp либо другого транспорта.

 

Простой арм7 вообще вымрет на этом.

HW кодек поставите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

HW кодек поставите.

В том и вопрос - а зачем себя ограничивать HW кодеком, если нормальный процессор сам справится с декодированием любого потока, и, если надо, с перекодированием его в другой? Вот, например, завтра придумают какой нибудь super-puper-aac, который все резко захотят, при программном декодировании надо будет лишь софт проапгрейдить, а при HW - увы-облом. Просто вопрос, что делается. Какой нибудь проект типа дипломного, туда да, PIC или Freescale с набортным PHY + HW codec самое то. Один раз сделал, запустил, выкинул. А если делается вещь с возможностью расширения и поддержки под новые стандарты - это другое. Две, так сказать, большие качественные разницы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А что по вопросу темы? Как вы смотрите на найденное мною решение?

Фирма поставщик контроллеров PIC18 сообщили, что возможно не смогут привезти указанный контроллер.

Как быть тогда? Могу ли я реализовывать связку ATmega128 + W5100 + 64КБ буферной памяти SRAM + VS1011 ???

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Могу ли я реализовывать связку ATmega128 + W5100 + 64КБ буферной памяти SRAM + VS1011 ???

Можете, и причем без проблем. И 128 у атмеги это гораздо больше, чем нужно реально в такой конфигурации. Но это будет как раз одно из тех решених, которые из серии "поиграться и выкинуть", так как не имеют перспективы в части модернизации и расширения. Да и Atmega+W5100 я бы заменил на MC9S12NE64 + PHY, правда чисто из учебных целей, так как к визнету (в виде W3100A) претензий не имею никаких, вполне удобная вещь, я пользовался им в свое время, правда вместе с TMS320VC5509.

 

А что по вопросу темы?

А по вопросу темы - я лично категорически против использования микросхем типа VS1101. Но не против визнета.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А если делается вещь с возможностью расширения и поддержки под новые стандарты - это другое. Две, так сказать, большие качественные разницы.

Ну дык может тогда сразу просто купить netbook с виндой и софт готовый взять. Можно будет не только радио слушать, но и кино смотреть...

 

А по вопросу темы - я лично категорически против использования микросхем типа VS1101. Но не против визнета.

А я бы посоветовал с точностью до наоборот, если от использования VS1101 есть хоть какой-то толк - mp3 лицензия, то Wiznet - это черный ящик открытого TCP стека - вещь абсолютно бестолковая и даже вредная.

Atmega+W5100 + 64KB внешней памяти - заменить лучше на LPC23xx / AT91SAM7Xxx + PHY

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...