Аудио через Ethernet

[DeGifted]

Хочу предложить обсудить следующую топологию звуковоспроизводящего устройства:

PC --Ethernet--> MCU --> Oversampling+FIR filter --> FIFO --> DAC --> I/U converter --> LPF --> attenuator --> amplifier

Работать должно так. Микроконтроллер с сетевым стеком слушает несколько TCP сокетов по разным портам для разных типов аудиоданных (44.1/16, 48/16 и т.п.). Полученные данные проходят через фильтр (кстати, думаю будет полезно иметь возможность отключать его с целью поиграться с программными оверсемплерами) и пишутся в FIFO, с которого забираются в DAC по клоку с генератора (должно быть два генератора, для 44.1kHz и 48kHz; нужный выбирается контроллером, в зависимости от того, на какой порт идут аудиоданные). Состояние FIFO отслеживается контроллером для управления скоростью вливания аудиоданных. Также для удобства несложно управлять с контроллера релейным регулятором громкости после DAC.
С компьютера аудиопоток по первому времени можно заливать даже с командной строки, что-то вроде cat rawaudio | nc 192.168.123.221 1234. А вообще неплохо бы написать драйвер для JACK или похожей технологии http://jackaudio.org/.

Что-то похожее уже реализовано различными фирмами, например Ethersound от Digigram. Но, к сожалению, я не нашёл доступных контроллеров ни для одной похожей технологии. Впрочем, пока это не выглядит слишком сложным, чтобы не попробовать реализовать самому.

Добавлено через 58 минут
Нашёл похожий DIY проект на стадии разработки. В качестве интерфейса автор использовал готовый модуль с перепрограммируемым FPGA (http://www.atmark-techno.com/en/prod...zaku/suzaku-s). Интересное решение, но не самое дешёвое. Пока что склоняюсь к Atmel семейству контроллеров с набортным Ethernet.
http://audio.peufeu.com/

[Gennadyi]

а это не оно ?
http://multimedia.nnm.ru/squeezebox_...zykalnyj_centr
http://multimedia.nnm.ru/transporter...zykalnyj_pleer

[Quasar]

что встроенной памяти не хватит на сетевые протоколы + звуковой буфер

На TCP/IP хватит вполне, еще хватит и на http...tftp...dhcp...dns...и т.п....вот со звуковым буффером уже менее ясно. Но если писать какой-то свой софт для винды, то нужно юзать MAC уровень....это кучу ресурсов освободит.

Предлагаю скооперироваться для разработки

Можно и скооперироваться .

Gennadyi
Для кого-то это может и оно, но вряд ли оно выдаёт честный i2s по внешнему клоку .

народ имхо не стоит тужится затачиваясь под определенную плату.

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

[Gennadyi]

Gennadyi
Для кого-то это может и оно, но вряд ли оно выдаёт честный i2s по внешнему клоку .

а Вы проверьте
вот это
- Входной тактовый сигнал «Word clock»: позволяет выполнять синхронизацию от внешнего источника тактовых импульсов

вместе с этим http://www.slimdevices.com/su_downloads.html

[Nikkov]

На TCP/IP хватит вполне, еще хватит и на http...tftp...dhcp...dns...и т.п....вот со звуковым буффером уже менее ясно. Но если писать какой-то свой софт для винды, то нужно юзать MAC уровень....это кучу ресурсов освободит.

Я примерно так же мыслю, но решил подстраховаться. Если памяти хватит, то в готовом устройстве его не будет.

Можно и скооперироваться .

С принципами построения еще не определялся? Здесь мне видится 2 подхода:
1) плата как сервер, в который комп пишет данные с нужной скоростью
2) комп как сервер, с которого плата читает файлы.

Первый вариант проще, но требует управления с компа, который скорее всего будет не слишком близко + требуется драйвер аудио/плагин к фубару (винампу и т.д.). Второй вариант реализовать сложнее, т.к. требует наличия интерфейса при помощи которого выбираются трэки.

Если второй вариант реализовать так: на компе есть прога-сервер, которая отдает контроллеру всю инфу, а интерфейс контроллера реализовать как управление CD-чейнджер, то и сложность получается не больше первого варианта, а удобство значительно выше.

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

Точно, плата здесь только для быстрого старта. А линух здесь будет лишним, т.к. ресурсы камней и так ограничены. Можно конечно взять АРМ9, но устройство на нем будет гораздо сложнее, а оно нам надо?
С драйверами связываться вообще не охота, да и не нужно это, IMXO

[ditter]

http://www.zao-zeo.ru/catalog/price.html
не рожайте ежа против шерсти

[Quasar]

http://www.zao-zeo.ru/catalog/price.html
не рожайте ежа против шерсти

У меня нет желания, применять линух только ради того что бы его применить....Ибо разбираться с ним, то же много времени уйдёт. Например с эзернетом и ARM7 я имею дело на работе постоянно, а с линухом на ARM9 дела не имел ни когда....ну и нафига мне этот гемор?

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

1) плата как сервер, в который комп пишет данные с нужной скоростью

Я думаю так. В интерфейсе будет простенький набор команд...типа там начать передачу в котором задается частота дискретизации, подтверждение принятого, запрос на новый пакет, ну и еще что-нибудь типа этого, более точно, продумать надо. Комп шлет команду начала передачи на mac устройства, ус-во отвечает, о том что готово...отсылается первый пакет, ус-во подтверждает о том что оно его приняло и т.п. В подтверждении можно передавать информацию о свободном объеме в FIFO. Объем FIFO можно выбрать в районе 16К.

С драйверами связываться вообще не охота, да и не нужно это, IMXO

Связываться-то конечно не охота, драйвера пускаются якобы в режиме ядра, и у них высокий приоритет...

[DeGifted]

Я думаю так. В интерфейсе будет простенький набор команд...типа там начать передачу в котором задается частота дискретизации, подтверждение принятого, запрос на новый пакет, ну и еще что-нибудь типа этого, более точно, продумать надо. Комп шлет команду начала передачи на mac устройства, ус-во отвечает, о том что готово...отсылается первый пакет, ус-во подтверждает о том что оно его приняло и т.п. В подтверждении можно передавать информацию о свободном объеме в FIFO. Объем FIFO можно выбрать в районе 16К.

И получится у тебя фактически тот-же асинхронный TCP ;). Всё-же считаю самым правильным и безгеморным гнать аудиопоток по TCP используя уже готовый сетевой стек. И посылать аудиоданные на такой дивайс с любой операционки - пара пустяков. Если мы строим хайэнд для воспроизведения музыки с компьютера, совместимость такого устройства с windows audio api по моему скромному мнению не обязательно и даже вредно ;).

PS: А протоколы типа ethersound используют MAC уровень из-за минимизации и предсказуемости задержек. Для студийного оборудования это важно.

Добавлено через 10 минут

а это не оно ?
http://multimedia.nnm.ru/squeezebox_...zykalnyj_centr
http://multimedia.nnm.ru/transporter...zykalnyj_pleer

Это ещё большой вопрос, что там и как в этой чудо коробочке устроено. К тому же изобретать колесо всегда так интересно ;).
Зато получив работающий дивайс PC->I2S можно открыть исходники и существенно облегчить труд других самодельщиков, пытающихся получить правильный звук с компьютера.

Добавлено через 13 минут

http://www.zao-zeo.ru/catalog/price.html
не рожайте ежа против шерсти

Так мы скоро придём к тому, что надо ставить PC и ваять для неё а-ля PCI soudcard ;). Я считаю что цифровой тракт между ЦАП и компьютером должен быть максимально простым и обеспечивать минимум функциональности: цифровую фильтрацию (и то, может быть, рациональнее это делать софтом на PC) и передачу потока на ЦАП. Чем проще будет схема, тем менее шумная и глючная она будет. В идеале неплохо бы вообще уйти от контроллера и реализовать всё что нужно в ПЛИС, используя один генератор для синхронизации всего.

[aal]

По первому виду: IR Control - ИК ДУ - самое то. Передача управляющих сообщений от девайса в РС. (Шоб к компу лишний раз не бегать...)

[ditter]

DeGifted,

Зато получив работающий дивайс PC->I2S

вообщето РСМ2707 и конструкций на его основе полно.

цифровую фильтрацию (и то, может быть, рациональнее это делать софтом на PC) и передачу потока на ЦАП. Чем проще будет схема, тем менее шумная и глючная она будет. В идеале неплохо бы вообще уйти от контроллера и реализовать всё что нужно в ПЛИС, используя один генератор для синхронизации всего.

вы что еще собрались и цап сами делать
я смотрю у вас налицо полное остуствие присутствия понимания задачи

[aal]

2 ditter
Здесь думают як сотворить чудо с внешней синхронизацией (от ЦАПа), а вы уже в который раз упоминаете пцм2ххх - ну не подходят они для внешней синхронизации и всЁ. А посему, пожалуйста, без оскорблений в адрес других участников. Не надо это вам - не пишите! Мы, надеюсь, поняли друг друга?

[ditter]

чудо внешней синхронизации просто делается заведением клока от цапа на GPIO АРМ7или9 . смотря на чем собрана плата. ну а проц используя кусок от имеющихся на борту 64 мб уже сам кусками выдает дата на цапу. задача проста и незатейлива.
теперь про якобы оскорбления. я их во первых не вижу а про непонимание задачи вкратце растолкую, ибо можно написать пару страниц почему так а не иначе но толку от этого не у будет.
- итак на своем опыте - схема цап рисуется за пару дней. остальной год она воплощается в железе.
на опыте своих друзей которые сами делали платку арм7+немного озу для светового табло - плата и заставить все работать это тоже год.
над обеими ветками проекта нужна работа как минимум 4х человек с опытом изготовления таких узлов.
подводных камней мильен в каждой ветке. а тут пишут такие перлы что грустно становится. IR Control из этой же серии, только вы не обижайтесь пожалуйста.
и самое интересное никто не говорит давайте возьмем готовое и срастим.
мы пойдем своим путем (с)
нюню. удачи
вот я и пишу про отсутствие понимание задачи.

[Nikkov]

чудо внешней синхронизации просто делается заведением клока от цапа на GPIO АРМ7или9 . смотря на чем собрана плата. ну а проц используя кусок от имеющихся на борту 64 мб уже сам кусками выдает дата на цапу. задача проста и незатейлива.
теперь про якобы оскорбления. я их во первых не вижу а про непонимание задачи вкратце растолкую, ибо можно написать пару страниц почему так а не иначе но толку от этого не у будет.
- итак на своем опыте - схема цап рисуется за пару дней. остальной год она воплощается в железе.
на опыте своих друзей которые сами делали платку арм7+немного озу для светового табло - плата и заставить все работать это тоже год.
над обеими ветками проекта нужна работа как минимум 4х человек с опытом изготовления таких узлов.
подводных камней мильен в каждой ветке. а тут пишут такие перлы что грустно становится. IR Control из этой же серии, только вы не обижайтесь пожалуйста.
и самое интересное никто не говорит давайте возьмем готовое и срастим.
мы пойдем своим путем (с)
нюню. удачи
вот я и пишу про отсутствие понимание задачи.

Если задачу ставить как получение конечного результата, вне зависимости от самого процесса его получения, то наверное, все так. Но, лично для меня, построение девайса своими руками на ARM7 и есть полцели. Вторая половина - это собственно ЦАП со входом Ethernet. А если ставить вопрос "давайте возьмем готовое и срастим", то тогда чем люди на этом форуме вообще занимаются? Что нет готовых колонок, усилителей или ЦАПов?
Насчет "просто делается заведением клока от цапа на GPIO АРМ7или9" в случае 7-го АРМа не тривиально, т.к. ресурсы будут забиты под завязку сетевыми протоколами, а указанные выше LPC23ХХ имеют аппаратную поддержку I2S с буфером, что позволит сэкономить эти самые ресурсы.
АРМ9 с SDRAM памятью и высокой частотой будет еще и источником достаточно высокого уровня помех (по сравнению с АРМ7).

Да, собственно, создание ЦАПов это тема не этой ветки, считаем, что он уже есть с выходом мастерклока. Задача: сделать нечто выдающее данные из сети синхронно с генератором ЦАПа

[Quasar]

ditter
Лично я, еще раз повторюсь, в схеме ARM9->Linux я ни чего готового не вижу (если вы всё про неё).

Nikkov

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

Вы слишком не до оцениваете ARM7 и переоцениваете TCP/IP протокол .

Да и к тому же в не initial ревизиях вроде как нормально работает DMA с I2S, это еще уменьшает загрузку камня.

PS. Да и вообще, че вы тут все про железку, да про железку, меня больше сам PC волнует. Что-то я пока не могу нащупать легкий и удобный способ вывода звука из PC и желательно без использования всего TCP/IP стека (я софт имею ввиду)...

[Nikkov]

Вы слишком не до оцениваете ARM7 и переоцениваете TCP/IP протокол .

Пока мои познания о максимально доступных скоростях стэков на АРМ7, черпаются из данных, которые приводят люди на форуме электроникс.ру, в разделе АРМ.
Тут лучше перебдеть, чем недобдеть

Да и к тому же в не initial ревизиях вроде как нормально работает DMA с I2S, это еще уменьшает загрузку камня.

Вот это я и имел в виду, когда писал "указанные выше LPC23ХХ имеют аппаратную поддержку I2S с буфером"

PS. Да и вообще, че вы тут все про железку, да про железку, меня больше сам PC волнует. Что-то я пока не могу нащупать легкий и удобный способ вывода звука из PC и желательно без использования всего TCP/IP стека (я софт имею ввиду)...

Меня это как раз меньше всего беспокоит . Написать программу направляющую в TCP/UDP порт поток данных не проблема, если есть устройство и протокол передачи. Мне хотелось бы попробовать RTCP, но есть большие сомнения в том, что АРМ7 его вытянет.

Offтопик:
Некоторое время назад писал программу читающую видеопоток с интернет-камеры, на которую был ее закрытый ActiveX компонент + сниффер и никакой программной документации ни о протоколах передачи, ни о применяемых форматах сжатия видео и звука. По ходу дела получил и поверхностные знания о MPEG4 и пр. Как не странно программа работает .

[Quasar]

По поводу скорости, конечно 100МБит не получишь, но например NicheLite OS по tftp давала что-то в районе 1Мбайта в секунду на загрузку, но NicheLite OS достаточно тяжелый код (там есть какое-то подобие файловой системы, можно включить что-то типа много поточности, ну и много еще всякой ереси ), поэтому, можно юзать какой-нибудь более легкий код и получить скорость 10-15Мбит, этого я думаю всем хватит .

Добавлено через 8 минут
А получить бОльшие скорости можно например снесением TCP/IP уровней , лично мне эта идея нравиться. MAC уровень у нас аппаратный, I2S у нас аппаратный, ядро в потолок плюёт . Намного упрощает задачу железки, но встает вопрос как это передавать от PC...С линухом пока не знаю, но вот Win32, как передавать, я уже понял, вот как получать пока нет

[Nikkov]

По поводу скорости, конечно 100МБит не получишь, но например NicheLite OS по tftp давала что-то в районе 1Мбайта в секунду на загрузку, но NicheLite OS достаточно тяжелый код (там есть какое-то подобие файловой системы, можно включить что-то типа много поточности, ну и много еще всякой ереси ), поэтому, можно юзать какой-нибудь более легкий код и получить скорость 10-15Мбит, этого я думаю всем хватит .

NicheLite - это уже из собственного опыта?

А получить бОльшие скорости можно например снесением TCP/IP уровней , лично мне эта идея нравиться. MAC уровень у нас аппаратный, I2S у нас аппаратный, ядро в потолок плюёт . Намного упрощает задачу железки, но встает вопрос как это передавать от PC...С линухом пока не знаю, но вот Win32, как передавать, я уже понял, вот как получать пока нет

Это я бы оставил на крайний случай. Переносимость у такого кода будет не очень

[aal]

У того же фубара есть айпи для написания плагинов, им и надо воспользоватся. Плагин ставится в цепочку дсп процессов в фубаре, на выходе он повторяет поток данных и одновременно его отдаёт в винсокет. Я токмо одного пока не знаю - как в фубаре регулируется скорость потока? Что её задаёт? Но есть где почитать...

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

2 Quasar Нам надо гарантированный поток порядка 10 мбит для 24/192 режима (1,2 мбайта в сек.). А управленческая часть мало весить будет... С более лёгким стеком это достижимо?

[DeGifted]

DeGifted, вообщето РСМ2707 и конструкций на его основе полно.

вы что еще собрались и цап сами делать
я смотрю у вас налицо полное остуствие присутствия понимания задачи

Судя по Вашим советам насчёт PCM2707 как-раз таки это Вы не в теме .
Разумеется я хочу собрать ЦАП, но пока что нужно решить проблему получения _правильного_ I2S с любимого плеера на компьютере.

[Quasar]

NicheLite - это уже из собственного опыта?

да.

2 Quasar Нам надо гарантированный поток порядка 10 мбит для 24/192 режима (1,2 мбайта в сек.). А управленческая часть мало весить будет... С более лёгким стеком это достижимо?

Я думаю да.(Думаю, потому что меня особо не интересовала раньше скорость передачи, и я не имею своей статистики по существующим стекам).

[Nikkov]

да.
Я думаю да.(Думаю, потому что меня особо не интересовала раньше скорость передачи, и я не имею своей статистики по существующим стекам).

Тогда получается даже тяжеловесного стэка хватит на CD-audio, причем комп может быть просто хранилищем с поднятым tftp сервером, а цап сам с него читать файлы (правда только PCM).
Интересны пропускные способности других вариантов (uIP и lwIP), мне плату неизвестно когда пришлют, пока в наличии нет, поэтому проверить не смогу, да и с АРМами пока дело не имел, нет желания протестировать?