Rst7 5 13 ноября, 2009 Опубликовано 13 ноября, 2009 · Жалоба Задачу "internet radio" сделать можно на самом дохлом ARM7. Выбросить mp3 вместе с TCP, реализовать UDP/RTP и какой-нить простенький потоковый кодек типа G.711 и будет щастье. С первой половиной утверждения вполне согласен. Со второй - нет. Ибо это будет узкозапиленное "радио". Хотя я бы целил в AAC, битрейт заметно ниже. И самое главное. Некоторые тонкости протокола TCP позволяют не предъявлять особых требований к количеству ОЗУ, занимаемому под буфер потока на приемной стороне. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Слесарь 9 13 ноября, 2009 Опубликовано 13 ноября, 2009 · Жалоба О це что попалось на глаза 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба Что-то мне подсказывает, что звук от такого кодека будет наипоганейшим.. Так что "щастье" будет недолгим... И после этого даже и не включать, потому как качество звука будет телефонным, а не аудио, и слушать такое радио будет невозможно Дык, после того как запустится с простым кодеком, что мешает поменять кодек на более толстый? И самое главное. Некоторые тонкости протокола TCP позволяют не предъявлять особых требований к количеству ОЗУ, занимаемому под буфер потока на приемной стороне. Это интересно какие такие тонкости TCP позволят не предъявлять особых требования к количеству ОЗУ на покрытие сетевого джиттера? При использовании TCP из плюсов имеем только: - гарантированную доставку из минусов: - overhead данных - необходимость отправки ACK'ов - невозможность использования broadcast и multicast сессий - потеря реалтайма Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба Это интересно какие такие тонкости TCP позволят не предъявлять особых требования к количеству ОЗУ на покрытие сетевого джиттера? Дело в том, что всякие трансляторы типа ShowCast при трансляции через TCP автоматически поддерживают нужный для приемника битрейт. Это снимает вопросы пересемплирования на приемной стороне (эта обратная связь через размер окна поддерживается). Это раз. Вторая фича связанна с потоковым характером данных, что позволяет при наличии поддержки Fast Retransmit в TCP-стеке обойтись буферами всего размером в 4 сегмента передачи (которые есть смысл выбрать достаточно малыми, например, размером байт в 700). Ну и конечно поддержка Delayed Ack - тоже необходимое условие. Наличие подтверждений каждого второго пакета практически не добавляет оверхеда. И кстати, большинство радиостанций в большом интернете вещают именно через TCP. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Слесарь 9 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба Дык, после того как запустится с простым кодеком, что мешает поменять кодек на более толстый? запас производительности. Например декодирование MPEG4 AAC (HEHQ профиль) 5.1 звука потребляет около 100 мегагерц C64+ ядра (вот по этим данным http://focus.ti.com/lit/ml/sprs369d/sprs369d.pdf, там Table 2). Простой арм7 вообще вымрет на этом. Ему дай бог справиться с самым простым тестом на LC. Ну а закладываться на внешний железячный кодек - это ограничить себя в возможности расширения функциональности продукта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба А вот такое посмотреть не хотите: 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. Ну а закладываться на внешний железячный кодек - это ограничить себя в возможности расширения функциональности продукта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба А вот такое посмотреть не хотите: https://datatype.helixcommunity.org/2005/aacfixptdec И чего туда смотреть? 6 каналов @ 96 КГц зажрут ~300 МГц. А еще захочется записать это в реалтайме на SD-карточку в MP3-формате. Так что тема кодеков не закрыта. Если ARM не Cortex-A8 на гигагерце. Если топовый кортекс - полностью с Вами согласен, выбор вполне подходящий, не хуже DSP. Но остро стоит тема подключения радиоприемников к интернету. Стоит крепко подумать о подключении через WiFi, WiMAX, 3G и т.д. Здесь так скажем DSP и рядом не лежали. И почему же они здесь не лежали? Вам религия не позволяет подключить WiFi-ник к DSP через mini-PCI (например), если надо? Мне лично позволяет. Прсото чип выбрать немного другой, с соотв. интерфейсом, и будет запас на расширение в этом направлении. Я при предложении исходил из интерфейса в вопросе автора. Я лично не вижу ни одной преграды для расширения и в этом направлении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба Ну в какой-то степени религия. :laughing: А что религия на пустом месте возникает? Вот где вы взяли исходники или спецификацию хотя-бы чтобы подключить WiFi по мини PCI. Народ с ног сбивается чтобы найти такую инфу, а у вас нет преград!? Такие вещи обычно дают в виде скомпилированных драйверов и только под две всем известные операционки, которые уж точно не портируются на DSP, а вот в ARM за 10$ и TQFP корпусе лехко! И почему же они здесь не лежали? Вам религия не позволяет подключить WiFi-ник к DSP через mini-PCI (например), если надо? Мне лично позволяет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 14 ноября, 2009 Опубликовано 14 ноября, 2009 · Жалоба Вот где вы взяли исходники или спецификацию хотя-бы чтобы подключить WiFi по мини PCI. Например проект DD-WRT, опенсурсный линукс под разномастные вайфайные маршрутизаторы. И это не единственное место добычи исходников для работы с мини-писиайными вайфайниками. Это касается исходников. Из них нижний уровень выдрать, а верхние они те же, что и для Eth. А документация - для ее получения, как правило, ничего кроме NDA производители этих штуковин (PCI-ных чипов) не требуют, т.е. преград нет, кроме предубеждения у некоторых против того, что NDA это нечто заоблачно-замудреное. Я же после опыта работы с фабами в части заказных ИМС к таким некоторым не отношусь. Что касается собрать - то компиляторы 6000-ные поддерживают немало gcc-шных расширений, в общим портирование проходит не напряжно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 15 ноября, 2009 Опубликовано 15 ноября, 2009 · Жалоба Дело в том, что всякие трансляторы типа ShowCast при трансляции через TCP автоматически поддерживают нужный для приемника битрейт. Это снимает вопросы пересемплирования на приемной стороне (эта обратная связь через размер окна поддерживается). Это раз. Вторая фича связанна с потоковым характером данных, что позволяет при наличии поддержки Fast Retransmit в TCP-стеке обойтись буферами всего размером в 4 сегмента RTP работает с media frame'ами. В случае трансляции радио - буфер привязывается не к некому сегменту, а к аудио фреймам, точнее к их времени. Т.е. если в TCP буфер измеряется в символах, то в RTP - в секундах(милисекундах). RTP - это протокол специально предназначенный для передачи media потоков. Автоматическая смена битрейта (для кодеков которые поддерживают разный битрейт) предусматривается стандартом. Это протоколы разных уровней, т.к. никто не мешает пользовать RTP over TCP. TCP это голый транспорт, самостоятельно без надстроек он не пригоден для решения поставленной задачи впринципе, точно также как RTP не сможет существовать без udp/tcp либо другого транспорта. Простой арм7 вообще вымрет на этом. HW кодек поставите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 15 ноября, 2009 Опубликовано 15 ноября, 2009 · Жалоба HW кодек поставите. В том и вопрос - а зачем себя ограничивать HW кодеком, если нормальный процессор сам справится с декодированием любого потока, и, если надо, с перекодированием его в другой? Вот, например, завтра придумают какой нибудь super-puper-aac, который все резко захотят, при программном декодировании надо будет лишь софт проапгрейдить, а при HW - увы-облом. Просто вопрос, что делается. Какой нибудь проект типа дипломного, туда да, PIC или Freescale с набортным PHY + HW codec самое то. Один раз сделал, запустил, выкинул. А если делается вещь с возможностью расширения и поддержки под новые стандарты - это другое. Две, так сказать, большие качественные разницы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Слесарь 9 15 ноября, 2009 Опубликовано 15 ноября, 2009 · Жалоба А что по вопросу темы? Как вы смотрите на найденное мною решение? Фирма поставщик контроллеров PIC18 сообщили, что возможно не смогут привезти указанный контроллер. Как быть тогда? Могу ли я реализовывать связку ATmega128 + W5100 + 64КБ буферной памяти SRAM + VS1011 ??? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 15 ноября, 2009 Опубликовано 15 ноября, 2009 · Жалоба Могу ли я реализовывать связку ATmega128 + W5100 + 64КБ буферной памяти SRAM + VS1011 ??? Можете, и причем без проблем. И 128 у атмеги это гораздо больше, чем нужно реально в такой конфигурации. Но это будет как раз одно из тех решених, которые из серии "поиграться и выкинуть", так как не имеют перспективы в части модернизации и расширения. Да и Atmega+W5100 я бы заменил на MC9S12NE64 + PHY, правда чисто из учебных целей, так как к визнету (в виде W3100A) претензий не имею никаких, вполне удобная вещь, я пользовался им в свое время, правда вместе с TMS320VC5509. А что по вопросу темы? А по вопросу темы - я лично категорически против использования микросхем типа VS1101. Но не против визнета. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 16 ноября, 2009 Опубликовано 16 ноября, 2009 · Жалоба А если делается вещь с возможностью расширения и поддержки под новые стандарты - это другое. Две, так сказать, большие качественные разницы. Ну дык может тогда сразу просто купить netbook с виндой и софт готовый взять. Можно будет не только радио слушать, но и кино смотреть... А по вопросу темы - я лично категорически против использования микросхем типа VS1101. Но не против визнета. А я бы посоветовал с точностью до наоборот, если от использования VS1101 есть хоть какой-то толк - mp3 лицензия, то Wiznet - это черный ящик открытого TCP стека - вещь абсолютно бестолковая и даже вредная. Atmega+W5100 + 64KB внешней памяти - заменить лучше на LPC23xx / AT91SAM7Xxx + PHY Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться