Сервер/рендерер/плеер на Cubieboard

[blindman]

Я тоже думал, что тут вопросов быть не должно 

[cu6apum]

Ну славтеяйца. Дык какая синхра по усб?! Цап просит подкинуть, комп кидает. С реклоком iis почти та же петрушка, только в грамотной реализации fifo вырождается в регистр-защелку.

[xar]

cu6apum, никто ни кого не просит. комп кидает и дай бог, чтоб цап не подавился.

[blindman]

Что происходит на USB - неважно. Главное, чтобы в ЦАП данные поступали в соответствии с его генератором. Asynchronous isochronous именно для этого и придуман

и добавил...
xar, нет, не так. комп выдает столько, сколько ЦАП скажет (в определенных пределах). Иначе будет тот самый synchronous mode - PCM2702 например

[cu6apum]

cu6apum, никто ни кого не просит. комп кидает и дай бог, чтоб цап не подавился.

Ренат, ну уж ты-то мог бы загуглить!! Я на этой собаке наелся уж костей, крупных и мелких. 

и добавил...
Николай, а ты круто продвинулся, судя по той ветке. Респектище! DoP еще не пробовал?

[blindman]

Так а буфер ДМА это что?

Синхронизированный с PLL процессора

[cu6apum]

Так, ветка кончилась, а про slave так ничего и не было. Ладно, фигли теоретизировать, трясти надо. Жду куби. В конце концов, для slave mode еще надо модуль клоков изобретать. Это хорошо, что ему mclk не надо!..

[blindman]

Я вовсе не против вывода IIS из контроллера напрямую к ЦАПу. Но предпочитаю буферизованный вывод, синхронизированный с ЦАПом.


и добавил...

ему mclk не надо!

Вот я про то же. Мне это не нравится

[xar]

xar, нет, не так. комп выдает столько, сколько ЦАП скажет (в определенных пределах).

а я почему то понял что цап сам решает что делать, чтоб переполнения буфера не было.

[cu6apum]

Я вовсе не против вывода IIS из контроллера напрямую к ЦАПу. Но предпочитаю буферизованный вывод, синхронизированный с ЦАПом.

Брр. Я тоже. О чем спорим?!

и добавил...

ему mclk не надо!

Вот я про то же. Мне это не нравится

Почему? Разве bclk не подойдет? Они ж кратны полюбасу.

[blindman]

а я почему то понял что цап сам решает что делать, чтоб переполнения буфера не было.

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

и добавил...

Разве bclk не подойдет? Они ж кратны полюбасу

Частота фрэймов USB тоже 1 кГц всяко разно. в теории. иначе бы не придумывали асинхронный режим

[xar]

blindman, то есть "переполнение буфера" происходит на компе где то в цепочке проигрыватель->драйвер?

[blindman]

В USB  устройстве может быть переполнение, если оно не успеет выплюнуть наружу все, что пришло от хоста по USB.

Грубо говоря: пусть в USB ЦАПе буфер 1024 байта. Чтобы не было переполнения, или опустошения, он его поддерживает заполненным, скажем на уровне 512 байт. По USB пакет передается каждые 125 мкС. При 44.1/16, каждые 125 мкС надо передать 5,5125 сэмплов. Вот девайс и следит за буфером. Если он больше 512 - говорит компу: в следующий раз передай мне 5 сэмплов.  Если меньше 512 - 6 сэмплов. Таким образом компенсируется как нецелое число сэмлов в пакете, так и разная точность опорных генераторов шины USB и девайса

[nikkov]

Так, ветка кончилась, а про slave так ничего и не было.

Да там с форумом проблемы были, последние посты потерялись. Для проверки SLAVE-режима я использовал формирователь бит-клока и фрэйм-клока на ПЛИС-ке http://forum.vegalab.ru/showthread.php?t=52167&p=1859479&viewfull=1#post1859479.

По поводу синхронности/не синхронности клоков и PLL. Для меня сложно понять, что тут непонятного  . Даже не думал, что это требует пояснения.
Видимо нужно объяснять как работает ДМА. Так вот, если упрощенно, у ДМА есть два буфера в которые процессор кладет данные, а I2S интерфейс забирает с частотой, равной фрэйм-клоку. Как только один буфер опустошается ДМА переходит на чтение второго, а процессор снова накидывает данные в первый буфер. И так повторяется пока идет воспроизведение. Все гораздо проще и надежней, чем с USB. И, повторяю, никаких проблем в том, что данные с буфера читаются с одной частотой, а пишутся с другой, гораздо более высокой. Точно так же, как и нет проблем в USB устройстве, которое работает обычно с частотой кратной 12 МГц, а выдает на цап данные с частотой кратной 44100.

[blindman]

Ну ежели так, то тогда да Но мне все же удобнее USB. Да и без ковыряния в драйверах задач нерешенных хватает

[cu6apum]

Николай, ну ты просто всё за меня сделал. 
Осталось разобраться с ПЛИСиной (вообще никогда не работал с) - и дело, вроде, в шляпе. Дсд не мучил еще?

[nikkov]

Николай, ну ты просто всё за меня сделал. 
Осталось разобраться с ПЛИСиной (вообще никогда не работал с) - и дело, вроде, в шляпе. Дсд не мучил еще?

Я для себя делал  . USB решения я освоил достаточно давно (поучаствовал в разработке open-source проекта SDR-Widget/Audio-Widget), поэтому это для меня пройденный этап. Да и куби я брал с целью скрестить его с USB Audio, но решил попробовать I2S, а так как получилось, то теперь это решение у меня в приоритете.
По поводу ПЛИС - я ее использовал для быстрой проверки slave-режима только потому, что у меня есть отладочная плата и сделать формирователь на ней очень просто. Целевое устройство я вижу иначе, так как, на мой взгляд, оно должно выполнять следующие функции:
1. формировать клоки
2. поддерживать внешний мастерклок
3. разнести кубик и цап в разные корпуса (т.к. соседство ЦПА-а и кубика с HDD в одном корпусе плохая идея)
4. обеспечивать гальваническую развязку с ЦАП-ом.

Поэтому сейчас я делаю это устройство как SPDIF-выход с внешней синхронизацией. В качестве SPDIF-передатчика и формирователя битклока и фрэймклока используется DIT4192, на плате стоят 2 генератора на 22.5792 МГц и 24.576 МГц, при подаче клока снаружи, встроенные гены отключаются и устройство тактируется внешним генератором. Выход SPDIF и вход внешнего мастер-клока развязаны трансформаторами, для переключения внешнего генератора (сетки 44/48) используется оптрон. Таким образом, без внешней синхронизации, устройство может использоваться для подключения к пром.устройствам с SPDIF входом, а с синхронизацией получаем бескомпромиссное устройство, гальванически развязанное от ЦАП-а.
С кубика к устройству, кроме I2S, подключаются 3 пина, на которые драйвер выводит сигналы переключения генераторов и делителей формирователя.

Со стандартом ДсД пока вообще не знаком, поэтому про него ничего не знаю.

[cu6apum]

Ну что ж, пора кооперироваться. Если есть желание, конечно.
В моем видении спдиф отсутствует, частота мастерклоков вдвое больше (для es9018 sync mode), остальное 1:1. Скажи, а 4192 вместо ПЛМки ты заюзал только из соображений вывода спдифа, или вообще выходит проще и лучше? В сущности, я мог бы купить на веге платку генераторов на 4192 и тоже изгаляться с нею, а не изучать ПЛМки с нуля...

[nikkov]

Ну что ж, пора кооперироваться. Если есть желание, конечно.
В моем видении спдиф отсутствует, частота мастерклоков вдвое больше (для es9018 sync mode), остальное 1:1. Скажи, а 4192 вместо ПЛМки ты заюзал только из соображений вывода спдифа, или вообще выходит проще и лучше? В сущности, я мог бы купить на веге платку генераторов на 4192 и тоже изгаляться с нею, а не изучать ПЛМки с нуля...

Я смысл в кооперации вижу в выборе софта для кубика, обмене опытом и информацией. А разработка универсального устройства, по моему, это утопия, так как у всех свое видение идеала.
4192 я использовал как устройство, убивающее всех зайцев, которых я хотел убить. Если ты хочешь использовать мастерклок более 25 МГц, то она уже не пойдет, надо смотреть что-то другое. Плата с веги (какая?) скорее всего не поддерживает мастера для I2S (по крайней мере я такую не видел).
Если не использовать SPDIF, то, опять же IMHO, лучше использовать простую ПЛИС. Это и более гибко, и компактно, плюс можно будет проверить поддержку 384 кГц (в мастере allwinner ее не поддерживает, но в слэйве очень даже может быть) и конфигурировать на разные мастерклоки. С ПЛИС-ами я тоже дела не имел, но такую простую задачу решить не сложно.

[cu6apum]

Солидарен. Сейчас довыздоравливаю, начну потихоньку ковырять код. Пока мастером хотя бы попробую, есть платка pcm5102 временно ненужная.
Плата генераторов - от некоего Энергетика на веге. Тоже на 4192, так что не актуальна: я уже глянул даташит. Будем врубаться в ПЛИСки, пригодится.
Спасибо за хороший старт!

[blindman]

По поводу софта

Я попробовал несколько реализаций рендерера, лучший вариант, по-моему - gmrenderer. Проект довольно старый, перестал поддерживаться. Один чувак из гугла его подхватил, довел до ума https://github.com/hzeller/gmrender-resurrect

Я туда еще добавил поддержку OpenHome https://github.com/ademenev/gmrender-resurrect-openhome

В чем преимущество OpenHome по сравнению со стандартом UPnP AV. Стандарт UPnP не предусматривает хранение плэйлистов на рендерере. Точнее, предусматривает, но реализация не стандартизирована, так что можно считать что поддержки нет. То есть чтобы проигрывать плэйлист, устройство управления должно следить за текущим трэком, и когда он закончился, подкидывать рендереру очередной. Если устройство управления не может следить за трэками, например мобильник отключился от сети, проигрывание прервется после окончания трэка. При использовании OpenHome, плэйлист хранится на рендерере. Можно накидать трэков, и отключить устройство управления - рендерер сам будет играть плэйлист

[nikkov]

А в чем смысл использования рендерера? Я пока думаю использовать кубик со своим HDD как отдельный автономный плеер + NAS, чтобы подкидывать ему файлы.

[blindman]

В том, что рендерер может быть в каждой комнате - или как я планирую, в комнате и на балконе, и играть файло с общего сервера. Что не мешает одному из рендереров иметь диск и работать также и сервером. Или иметь отдельный сервер. Или играть контент с 2 и более серверов.  И в то же время быть и контролпоинтом - в сумме эти 3 компонента и дают плеер. Захотел - управляй им непосредственно, с пульта. Или включил телефон с вафлей - и с него рули

[nikkov]

В том, что рендерер может быть в каждой комнате - или как я планирую, в комнате и на балконе, и играть файло с общего сервера. Что не мешает одному из рендереров иметь диск и работать также и сервером. Или иметь отдельный сервер. Или играть контент с 2 и более серверов.  И в то же время быть и контролпоинтом - в сумме эти 3 компонента и дают плеер. Захотел - управляй им непосредственно, с пульта. Или включил телефон с вафлей - и с него рули

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

Я пока на кубике с mpd тестирую, пока вроде все устраивает.

[blindman]

устройство, выводящее звук, который транслируется с некоего сервера

Так и есть. Но это ж компьютеры. И есть такие понятия, как физическое устройство и логическое.

Я, честно говоря, не совсем понимаю, о чем разговор. Если просто непонятно что-то - давайте конкретные вопросы. Если же речь о том, что рендерер как таковой не нужен ... ну это как atmel vs pic. или байк супротив "табуретки".

[nikkov]

устройство, выводящее звук, который транслируется с некоего сервера

Так и есть. Но это ж компьютеры. И есть такие понятия, как физическое устройство и логическое.

Я, честно говоря, не совсем понимаю, о чем разговор. Если просто непонятно что-то - давайте конкретные вопросы. Если же речь о том, что рендерер как таковой не нужен ... ну это как atmel vs pic. или байк супротив "табуретки".

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

[cu6apum]

Николай,  так 192 выводили, молотит без проблем? Я сейчас накапливаю первый ящик знаний по теме. Говорят, через XMOS+USB затыкается и ерзает, недостает мозгов.

[blindman]

Говорят, через XMOS+USB затыкается и ерзает, недостает мозгов

Или брешут, или XMOS не тянет. С моим USB транспортом и Lynx D29 на флаках проблем не было

[cu6apum]

Говорят, через XMOS+USB затыкается и ерзает, недостает мозгов

Или брешут, или XMOS не тянет. С моим USB транспортом и Lynx D29 на флаках проблем не было

У тебя именно третий куби?

[blindman]

Первый