Hyper Transport

[alexandermas]

... в общем то это продолжение темы opensource usb transport, но ввиду того что в той теме
так нафлудили что решил завести новую. Да простят меня модераторы. во-первых: проект потерял
статус opensource так как на мое предложение поработать сообща отозвалось очень немногие,
а из этих немногих отпочковались почти все. Почему почти, потому что в конце останется
только один . И он остался и им оказался AAL. С ним мы и продолжили разработку....
И собственно вот что мы имеем на данный момент:

• работа с usb/ftp/smb(сеть windows)*
• управление сенсор/сеть по udp (собственное ПО под WIN пока BETA планируются версии android\macos) планируется api для создания собственных(пользовательских) программ воспроизведения/управления
• дисплей 480х272 TFT
• flac 16/24bit 44100-384000hz
• alac 16/24bit 44100-384000hz
• ape 16/24bit пока только 44100-48000hz
• wv 16/24 44100-192000hz
• wav 16/24bit 44100-768000гц
• mp3 до 320 kbps
• ac3 до 320 kbps
• интернет радио
• обучаемый ик пульт*
• выходы i2s (rj/lj48, rj/lj64 ,i2s48/64),spdif
• входы spdif*, usb(stream audio)*,i2s*
• поддержка cue, m3u, встроенных cue, логотипов альбомов
• база данных медиа библиотеки лдя комфортного выбора контента*
• создание/редактирование собственных плейлистов, добавление трека в режиме воспроизведения к теневому плейлисту, удаленная загрузка плейлистов*
• урпавление цф цап, рг.громкости*, коммутатором входов*
• usb мультиплексор и возможность внутреннего usb накопителя (это когда в плеере стоит встроенный usb-hdd,

но можно подключить внешний и посмотреть на него через usb до ПК или через сеть)

• автообновление ПО через интернет*
• тактирование бОльшего числа компонентов от мастерклока(дисплейный модуль, все настраиваемые выходы управления).
• автоопределение заведенного мастерклока*

знаком *** помечены сырые или недоделаные опции. Это значит что они точно будут включены в проект,
проработаны с точки зрения hardware, включены в первую ревизию плат но не включены в прошивку или неотлажены.

hardware arm(CM4)+fpga+sdram)

Небольшая ремарка по поводу freertos и вообще ос в подобных проектах собственное мнение: по
большому счету минималистичная ос реального времени, а freertos по сути как
не такая уж помеха для высококачественного вывода звука если ее правильно приготовить. Она лишь упрщает
жизнь программиста. Потому как для одновременного проигрования музыки, отображения чего либо на экране,
работы системы управления и чего то еще все равно требуется многозадачность. Иначе нельзя было бы
переключить трек или выключить ус-во во время проигрования музыки. Не спорю, можно добиться того же
результата и без ос, но в основной программе все равно приходится находить время и обслуживать так
называемые неосновные процессы. Но мы теряем еще один плюс - гибкость и масштабируемость системы в
целом. Например добавление дополнительного модуля может привести к полной неработоспособности системы
ввиду слета всех таймингов. Что касается систем с ОС там этим занимается сама ОС. И если правильно ее
настроить и доработать можно добиться вполне достойных результатов....

[Ромыч]

Честно говоря, мы даже самим себе порой не можем до конца объяснить - чего мы хотим от цифрового аудиотранспорта.

Да просто не надо от него хотеть того, чего он вам не должен по определению

Ну фиг знает, пишу о том, с чем столкнулся лично Тоже понадеявшись на универсальность i2s и обещаний одного забугорного разраба, что его i2s ЦАП работает с Raspi, купил, подключил, и ничего не получилось. Пришлось докупать USB/XMOS - i2s модуль, и менять малинку на Cubie.
Если в данном случае предполагается полная совместимость с любыми i2s ЦАП-ами (не только существующими, но и теми, которые могут появиться в обозримом будущем), без перепрограммирования транспорта - респект!

Както слабо верится, что у вашего разраба какойто особый И2С в цапе, независимо от наличия бугра между вами.

[aal]

брать устройство с немалым ценником на один день имхо не разумно.

На один день - да. Но: 1. кто сказал, что ценник будет не малый? 2. Что такое не малый? Для разных людей это разное. 3. зачем подобное на 1 день?

1. скины на дисплей

Второе ценное предложение. Но в общем это относительно не сложно.

2. гибко конфигурируемые выходы управления (для управления различными ЦАПами),

Заложено уже: лог. выходы, SPI, I2C.

управление от ИК

уже заявлено.

3. возможность раздельного вывода L и R данных, для подключения без ЦФ

заложено изначально, но не объявлено, т.к. эти опции как и ЦФ предполагаются, но не отработаны и посему пока не заявлены. Предусмотрен вывод DSD, но разбор форматов файлов ещё не производился. DSD over spdif тоже заложен и помоему даже сделан был в одном из вариантов прошивки fpga.

Если в данном случае предполагается полная совместимость с любыми i2s ЦАП-ами (не только существующими, но и теми, которые могут появиться в обозримом будущем), без перепрограммирования транспорта - респект!

Кто в курсе, тот увидел в описании все форматы I2S на сегодняшний день. Что будет завтра и насколько легко это будет добавить - поживём увидим. (ИМХО особого смысла что-то добавлять в сам формат уже нет + он вполне работоспособен и при достаточно сильном изменении форматов хранения звука.)

Единственно что не было явно заявлено, это поддерживаемые частоты мастер клока. Реально можно сделать от 256Fs до 1024 и выше. Без гемороя 512 и 1024. В ТЗ закладывалось от 384 до 1024Fs. При частотах менее 512 отрезается форматы выше 192кГц - сам цап их тогда не поймёт.

ну это как бы шутка, но если в этом устройстве часть опций подсократить (в частности, некоторые выходы), то может примерно так и получиться.

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

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

Саш - не только этим всё определяется. Не спорю, важный фактор, но и не менее важный спесь и жадность производителя. Боюсь что здесь это есть и/или не учитывается цена ещё ЦАПа - её надо отнять от цены девайса.

В том что я говорю о непродуманности управления и отображения?

А где у нас дано полное описание этого?

Управлять предлагается обычным пультом, глядя с расстояния несколько метров на маленький экранчик (большой заставит увеличивать размеры корпуса) разрешением 480х272. Не нужно говорить, что управлять плэйлистами, списками, каталогами таким образом мягко говоря не совсем удобно. Не зря многие пользователи не желают "спрыгивать" с компьютера в качестве транспорта. Да, в наличии есть bета проги управления для винды, планируется для macos, но позвольте вопрос: в чем смысл этого транспорта, если управлять все равно с компа? Фубар и лирк не стоят ничего. Управление с планшета (пользуюсь сам - очень удобно) в отдаленной перспективе, и то только для ведра или предлагается написать самому

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

при этом транспорт позиционируется как сабж для людей не знакомых с програмированием. Все написаное сугубо имхо и токмо с целью совершенствования проекта.
P.S. не реклама, просто посмотрите как работает на клиент на огрызке (цена проги 169 рублей) https://www.youtube.com/watch?v=APwDFS6NK7Y

Одно другому не мешает. Тем паче вы не знаете механизма такой возможности.
За видео спасибо конечно, но:
1. это не просто огрызок, это планшет с большим экраном.
2. кто разоряется на такой транспорт не обязан раззоряться ещё и на планшет.
3. высота большинства корпусов, в разумном пределе, не позволяет ставить экраны более 5" - именно с этим авторы упомянутого выше плеера сделали откидной экран. Не наш вариант.
4. т.е. нужно так организовать управление, чтобы и на малом экране всё поместить - а вот именно здесь нужно серьёзно потрудится. Т.е. прежде чем давать такие советы стоит оценить специфику....

Wired, в этой ветке "linux" - ругательное слово. Надо свои кактусы съесть

нет. Просто здесь этому уже не место: выбор сделан, работа проведена. Как сравнение - пожалуйста, но тогда и развёрнутое сравнение.
SanSound,
Wired, СПАСИБО!

А если время трека превышает 1 час?
Imho, для 5* дисплея размер бегущей строки маловат.
Imho, одна иконка Hi-Res - тоже маловато будет: 48000*24 - хайрез? 192000*24 - вроде хайрез

Эти мелочи продуманы - хотя для многих они будут, при реальном использовании, надуманными

[JazMan]

Прочитал.

Как мне думается, будущее за транспортами, удобными и разными. К примеру, эзернет не охвачен, Audio Video Bridging (AVB)?
Соединил роутер с ЦАП, и гоняй музыку с чего хочешь (в идеале).

[aal]

Всего не охватишь, но коли есть потребность и возможность - почему нет? Будет время, будут запросы - может и будет реализовано.

Могу сказать, что мне очень хотелось получить UPNP сначала, но разбор полузакрытого формата - та ещё трабла, а вырождение его в закрытый DLNA поставила крест. А как красиво смотрелось в начале: ничего в плеере, токмо вывод, а все декодеры на хосте.

Так захотелось дать отповедь любителям рюшечек, даже слоган придумал: "не с Hello Word учить программированию надо было!"
Но наверно скажу иначе: "любой каприз за ваши деньги". А вот захотите ли вы за это переплачивать - вопрос к вам. Основное то было сделать низкоуровневые обработчики файлов, форматов, протоколов, кодеков.

Совсем забыл сказать, что с небольшими программными доработками возможно будет функция рекордера , а интерфейс не только I2S, но и пром АЦП можно заложить. Эта тема обсуждалась. Сложностей не будет. Другое дело, что не стали сразу делать сжималку: скоростью накопителя будут ограничены максимальные форматы по частотам, а запись только PCM (Wav). (можно и dsd наверно сделать, но пока запроса не было - тех. ограничений тоже нет.)
Чтобы это было реализовано нужно будет создать небольшую группу желающих этого функционала.

Для понимания такой гибкости стоит сказать, что под аудио интерфейсы, управление ими отведено порядка 40 ног fpga и только часть будет жёстко зафиксирована на разъёмах со стандартной цокалёвкой. Кто в теме - тот поймёт что можно здесь нагородить. К тому же если вы напишете свой модуль ввода/вывод на vhdl (тестирование за вами, за нами только имплементация в прошивку) - то и его можно получить в составе обновлённой прошивки под вас конкретно. В первую очередь это касается пром интерфейсов SPI подобных.

Скинов не будет: будут темы (цветовые гаммы) может быть, с небольшим изменением дизайна.

[JazMan]

Могу сказать, что мне очень хотелось получить UPNP сначала, но разбор полузакрытого формата - та ещё трабла, а вырождение его в закрытый DLNA поставила крест. А как красиво смотрелось в начале: ничего в плеере, токмо вывод, а все декодеры на хосте.

Да, это было бы интересно.

[forever_student]

...Эти мелочи продуманы - хотя для многих они будут, при реальном использовании, надуманными

Imho, вопрос интерфейса - второй вопрос по важности после собственно качественного воспроизведения. Какие уж тут мелочи...
А как то, что продумано, работает - секрет?
Размер шрифта зависит от длины трека (если я правильно понял alexandermas)? Imho, это на "продумано" не тянет...

P. S. Если дисплей, просто "чтоб было" - тогда вопросов нет.

[aal]

Imho, вопрос интерфейса - второй вопрос по важности после собственно качественного воспроизведения. Какие уж тут мелочи...

Его важность мы вполне осознаём. А мелочи было сказано именно о конкретно ваших замечаниях.

А как то, что продумано, работает - секрет?

Ветка создавалась не столько похвастаться, сколько посмотреть что мы не учли и что требует доработки. Будет предсерийный вариант плеера - всё покажем в видео. + к тому времени кое-какие вещи будут доработаны именно исходя из ваших замечаний.

Размер шрифта зависит от длины трека (если я правильно понял alexandermas)? Imho, это на "продумано" не тянет...

Это как раз те мелочи/хитрости, которые можно обсудить. Но само решение по своему элегантно - читабельность на расстоянии не падает в 99,9% случаев.

P. S. Если дисплей, просто "чтоб было" - тогда вопросов нет.

Он опция (опция: "Не хочешь? - Не покупай!"), но и далеко не так, как вы сказали. Те, кто выберет такой вариант управления должны получить проф. сделанную и продуманную версию интерфейса. А вот под андрюшу боюсь я долго буду рисовать управлялку и далеко не сразу она станет красивой и удобной. Рабочей - да, сразу. Хотя подводных камней вроде хватает...

Кстати, то же не упомянуто: энкодер ("крутилка") со встроенной кнопкой тоже бедут на плате индикации/цепляться к плате. Его наличие облегчает управление и увеличивает его скорость, снижает кол-во ошибок управления.

---------- Сообщение добавлено 02.07 ---------- Предыдущее сообщение было 02.04 ----------

Да, это было бы интересно.

Кстати, Александр не просто так сказал о загрузке проца - т.е. задел на обработку XML ещё есть и не малый (Даже его парсер был написан, но это малая часть того пласта знаний, что нужны для реализации UPNP) И для этого очень пригодится SDRAM

[JazMan]

Кстати, Александр не просто так сказал о загрузке проца - т.е. задел на обработку XML ещё есть и не малый (Даже его парсер был написан, но это малая часть того пласта знаний, что нужны для реализации UPNP) И для этого очень пригодится SDRAM

Offтопик:
Если речь об обычном, текстовом XML, парсеров готовых под сотню, на любой вкус...

[aal]

Offтопик:
JazMan, В любом случае бабла на вступление в DLNA форум мы не наскребём, да и так ли стоит стараться их наскрести?

[forever_student]

...Ветка создавалась не столько похвастаться, сколько посмотреть что мы не учли и что требует доработки...

Тогда, imho, для замечаний/предложений должно быть как можно более полное описание (с т.з. пользователя) что и как работает/включается/выключается.

[JazMan]

Offтопик:
JazMan, В любом случае бабла на вступление в DLNA форум мы не наскребём, да и так ли стоит стараться их наскрести?

Offтопик:
Не обязательно упираться в DLNA.
В том же линуксе есть несколько вариантов сетевого аудио, и возможно, что-то в винду уже спортировали... или можно самому плагин для foobar2000 налепить)

[aal]

Тогда, imho, для замечаний/предложений должно быть как можно более полное описание (с т.з. пользователя) что и как работает/включается/выключается.

Всему своё время и место. Ну привели бы мы это сразу - один чёрт сначала надо было от малинок отбиться , но "интрига" была бы утеряна и обсуждения бы не было. Самое то забавное: основные замечания не по железу далеко, и даже не по основному функционалу, а чаще по рюшечкам. Т.е. либо всех всё устраивает, либо ждут пока "залётные" улетят флудить в другое место.

Offтопик:
Не обязательно упираться в DLNA.
В том же линуксе есть несколько вариантов сетевого аудио, и возможно, что-то в винду уже спортировали... или можно самому плагин для foobar2000 налепить)

Вы наверно не понял: в dlna не было такого функционала. Для этого есть другие пути решения, но и этот не самый забытый: кобра была одной из первых, сейчас наверно именно AVB претендует на эту роль - поживём увидим.

---------- Сообщение добавлено 03.07 ---------- Предыдущее сообщение было 02.43 ----------

Сейчас была основная цель отладить основу и получить гибкий контроллер для этого. Сейчас основное: сделать железо в виде готовой платы и довести именно встроенный интерфейс до какого-то приемлемого начального варианта. А потом напирать в основном на добавление функционала. И именно на том этапе можно будет покуролесить вдосталь с интерфесами и технологиями - запас есть и не малый. Вот когда упрёмся в ограничения по железу можно будет думать о его совершенствовании.

Но и здесь прогресс не стоит на месте: после выбора целевого проца уже появилось несколько десятков процов на вариант замены. Не все оптимальны, но я уверен, что через пару лет будут ещё более продвинутые: тот же sdram уже сейчас является узким местом (мы подошли если не вплотную, то близко к этому на хайрезах) - очевидный шаг: ddr память - переход на неё отодвинет это ограничение ещё на долгий срок. (Да, да именно sdram - проц может обсчитать гораздо больше, но упрётся всё именно в память.) Оптимизация потоков может дать немного, но и сейчас они достаточно оптимальны: экспериментов была масса, было применено и программное кэширование во внутреннюю память - её блочность со своими шинами позволяет многое разрулить. В будущих процах именно на это будет сделан не малый упор. ИМХО.
Сейчас спасет то, что реалтайм (всмысле проигрывания фалов) востребован не на всех интерфейсах одновременно: если работаем по сети, то нет потока по юсб, а если по юсб то сеть не грузит лишним, если копируем файлы, то они не имеют того же приоритета, что проигрываемые (или не играем их в это время для ускорения копирования.)

[forever_student]

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

Imho, узкое место - программа, которая работает с SDRAM.
В моём транспорте SDRAM на частоте менее 50 МГц успевает и 192000*24 и дисплей (800*480*24бит 60Гц)

[А.К.]

управление от ИК

т.е. есть возможность настроить управление выходами (в т.ч. SPI, I2C) по ИК командам?

[ass77]

Сообщение от ass77
брать устройство с немалым ценником на один день имхо не разумно.
На один день - да. Но: 1. кто сказал, что ценник будет не малый? 2. Что такое не малый? Для разных людей это разное. 3. зачем подобное на 1 день?

Если внимательно посмотреть, то эта моя фраза касалась не Вашего устройства. Ответ был Ромычу по поводу поддержки Дюной 384 кГц.

А где у нас дано полное описание этого?

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

Вроде как в первом посте написано.

управление сенсор/сеть по udp (собственное ПО под WIN пока BETA планируются версии android\macos) планируется api для создания собственных(пользовательских) программ воспроизведения/управления
дисплей 480х272 TFT
обучаемый ик пульт*

Если как-то по другому, тогда извините и опишите подробней, а не обижайтесь.

это не просто огрызок, это планшет с большим экраном.

Словом "огрызок" я лишь обозначил известного производителя. Смею Вас уверить, что такая же программа (только бесплатная) установленная на телефоне от того же производителя работает не хуже.

кто разоряется на такой транспорт не обязан раззоряться ещё и на планшет.

Странная логика. Следуя ей пользователь Вашего девайса должен "разориться" на компьютер, флэшки, роутер, ЦАП, усилитель, акустику...
Почему Вы не допускаете, что планшет/смартфон уже есть в наличии и возможность его использования есть хороший +

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

[alexandermas]

Imho, узкое место - программа, которая работает с SDRAM.
В моём транспорте SDRAM на частоте менее 50 МГц успевает и 192000*24 и дисплей (800*480*24бит 60Гц)

Насколько я понял из темы о вашем транспорте пока не реализовано поддержки ни одного сжатого формата? А вы попробуйте учинить битовое чтение из sd-ram и а потом сравним как и что. Для информации скажу что для 44100-16 скорость должна быть примерно 1.1 мегабит, а для 192 порядка 6.4 мегабита, а учитывая что у вас не sram и протокол обмена там другой, да еще если нет шинного фифо хотябы на несколько слов , а у вас будет чтение вразнобой потому как еще и экран нужно обновлять. Так что незнаю-незнаю как и что получится у вас на 50мгц. Мне это видится в работе так: при хорошей оптимизации кода либо будут провалы в звуке либо проблемы с экраном. В виде подсказки: я бы понизил частоту экрана до 28-30гц, забил бы на 24бита в цвете сделал бы rgb565, и битовый буффер сделал бы в оперативе проца, пользовал бы 32бит сдрам, все переменные держал бы там же(в проце). потому как на 50мгц пропускная шины около 200мбайт/c при условии 32бит памяти, из которых четверть тратиться на экран. Хотя если держать во внешней памяти только большие буфера, вполне возможно.... Немного скажу о своих декодерах флак до 96000-24 я успеваю распаковывать на скорости камня 48мгц и частоте sdram 24мгц (там только выходной буффер 1мб и все). А для работы дисплея sdram не используется вообще, т.к. использован достаточно интересный контроллер дисплея который львиную долю работы берет на себя, который и работает то по spi шине на частоте мастерклока. И это тоже обдуманный выбор. Посмотрим, возможно я и не прав, но распаковки больше 96кгц вам вряд ли удастся добиться. Про динамическую индикацию во время воспроизведения можно вообще забыть. (имеется ввиду нечто большее чем время и прогрессбар). И я не критикую вашу систему, мне наоборот очень интересно если вы все же добьетесь необходимых скоростей.

[Anr]

Прочел ветку, но не увидел ничего о многоканальности. Как у Вас с этим?

[forever_student]

Насколько я понял из темы о вашем транспорте пока не реализовано поддержки ни одного сжатого формата? А вы попробуйте учинить битовое чтение из sd-ram и а потом сравним как и что...

Сейчас пишу декодер flac, так что немножко в теме.
- А не проще из SDRAM читать 32-бит слово во внутреннюю SRAM, и там изгаляться как угодно?
- У меня в декодере SDRAM вообще никак не используется, стало быть, на её пропускную способность декодирование никак не повлияет.

...Мне это видится в работе так: при хорошей оптимизации кода либо будут провалы в звуке либо проблемы с экраном. В виде подсказки: я бы понизил частоту экрана до 28-30гц, забил бы на 24бита в цвете сделал бы rgb565, и битовый буффер сделал бы в оперативе проца, пользовал бы 32бит сдрам, все переменные держал бы там же(в проце). потому как на 50мгц пропускная шины около 200мбайт/c при условии 32бит памяти, из которых четверть тратиться на экран...

Вам видится, а мне ещё и не слышится: ни провалов звука, ни проблем с экраном...Может, я чего не так делаю?
Спасибо за подсказку, но всё и так отлично работает, зачем менять? Когда напишу декодеры, возможно, ещё понижу такт проца и SDRAM.
Битовый буфер не нужен, память и так 32-бит, чуть больше трети пропускной способности SDRAM тратится на экран, из оставшихся 2/3 маленький кусочек на ввод-вывод 192000*24, остальное - резерв. О каком ограничении SDRAM вообще тут говорить?

...Немного скажу о своих декодерах флак до 96000-24 я успеваю распаковывать на скорости камня 48мгц и частоте sdram 24мгц...

В каких-то документах на тот МК, что я использую, написано, что для декодирования mp3 ему нужно всего 15МГц...

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

Т.е. у него есть свой МК с генератором и видеопамятью? Imho, такое решение облегчает подключение, но имеет кучу минусов.

...Посмотрим, возможно я и не прав, но распаковки больше 96кгц вам вряд ли удастся добиться...

Смелый прогноз!

...Про динамическую индикацию во время воспроизведения можно вообще забыть. (имеется ввиду нечто большее чем время и прогрессбар)...

Слушаюсь! Уже забыл!

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

Но речь в общем-то о Вашей системе, я просто показал, что при соответствующем подходе до ограничения SDRAM очень далеко.

[alexandermas]

Прочел ветку, но не увидел ничего о многоканальности. Как у Вас с этим?

Аппаратно платформа позволяет сделать и 7.1 и 8 и 28 другое дело насколько это нужно. Скажем так, что поток 5.1 на 96кгц распаковать я смогу а может и на 192 смогу. вывести тоже вроде не проблема. Были мысли замутить кроссовер в плис, но про это были только разговоры. Может сделаю а может и нет. Смотря что имеется ввиду под многоканальностью. Если кроссовер может и сделаю когда нибудь, а если просто многоканал, то наверное нет. У вас например много такого контента в фонотеке? У меня нет....

[Anr]

...имеется ввиду под многоканальностью. Если кроссовер может и сделаю когда нибудь, а если просто многоканал, то наверное нет. У вас например много такого контента в фонотеке? У меня нет....

Жаль что Вы похоронили многоканал... Мне кажется, что это могло быть востребовано. А идея кроссовера - это класс!