ЦАП DSD Signalyst DSC1 — DIY

,

ребят. а кто знает какой платой можно вытащить i2s для dsc1 из hdmi видеокарты?

Вопрос уже поднимался на Diyaudio.

та карабушка давно снята с производства и марально устарела, эта пойдёт? https://www.audiophonics.fr/en/diy-interfaces/audio-gd-diy-kit-i2s-to-hdmi-output-module-p-9347.html

Во-первых, вывод нативного DSD over HDMI с бытовых видеокарт заблокирован аппаратно. Т.е. вывести можно только инкапсулированный в DoP DSD64, который чем-то надо обратно преобразовать в DSD-raw.
Во-вторых, приведенная плата ВЫВОДА audio-gd в этом деле не поможет, т.к. поддерживает только PCM, да и от HDMI там только разъем - сигнал либо TTL, либо LVDS.
Существуют специализированные платы приемников/передатчиков LVDS over HDMI - to - DSD от Yanasoft.

1 лайк

а это оно? https://ru.aliexpress.com/item/HDMI-to-IIS-I2S-DSD-send-board-output-board/32817016085.html?spm=a2g0v.10010108.1000014.1.11de46c4vHl8Gb&traffic_analysisId=recommend_3035_null_null_null&scm=1007.13338.98426.000000000000000&pvid=49370a5e-36b3-48cc-80ac-3f022665c1a4&tpp=1

читали? http://yanasoft.jp/yana/R2R_DAC2_1_0.pdf

Это китайский аналог приведенного выше передатчика по дифференциальному интерфейсу LVDS. Какой источник планируется состыковать с DSC1?

хочу по hdmi на dsc1 на маке на перспективу для поканалки, а сейчас бы с odroid c2 на dsc по i2s

По hdmi с мака не взлетит, а для odroid c2 есть DoP decoder и изолятор с реклоком:
https://github.com/iancanada/DocumentDownload

Не могу понять, почему не используется возможность формирования логики 595 в ПЛИС, а закладываются дискретные HC595? Я в том числе и про проект 1021/1121, где ПЛИС уже заложена.? :thinking:

Тоже думал развести DSC на ПЛИС(может когда нибудь экспериментально сделаю такую плату). Но в итоге на россыпи такие вещи получаются “проще” и интереснее, чем с использованием плис.

Преимущества ПЛИС понятны, поэтому перечислю ее недостатки:

  1. Новые ПЛИС используют в качестве питания максимум 3.3В - У DSC и так не сильно большой выходной сигнал 1,7Vrms, c ПЛИС будет <1,1Vrms.

  2. Сложно обеспечить качественное питание, от которого напрямую зависит качество звука. У ПЛИС обычно от 1 до 4 входов по питанию, в то время как с 595 получается 16 точек питания - по одной точке на каждые 8 бит. При чем вокруг этих точек можно заложить достаточное пространство для качественной фильтрации каждой из них. В ПЛИС придется очень сильно ужиматься или переносить элементы на другую сторону платы.

  3. В современных ПЛИС очень сложно добиться одновременной согласованности переключения всех битов. Вот такая картинка у меня получалась при закладывании алгоритма AFIR фильтра в EPM270 с автоматическим распределением логических элементов по блокам ПЛИС: http://forum.vegalab.ru/showthread.php?t=77582&page=3&p=2387386&viewfull=1#post2387386. Возможно разница переключения в 1-2 нс не критична и полезна для “распределения” интенсивности шумов переключения во времени. Но все же.

  4. При использовании новых 8t595 возможно разделение веток Аналогового и цифрового питания без дополнительных микросхем.

  5. Необходимо разводить дополнительные пины для программирования ПЛИС, а так же иметь в обиходе “Blaster” для прошивки ПЛИС.

С другой стороны никто не запрещает сделать такой проект на ПЛИС. было бы интересно.
А в Soekris, на ПЛИС, на сколько я знаю, используется больше как ЦФ с подгружаемыми настройками FIR фильтрации. В случае DSC эту задачу выполняет либо компьютер, либо AK4137. На счет прикладной нагрузки ПЛИС в Soekris точнее подскажет Виталий (@VitB).

2 лайка

Благодарю за развернутый ответ. Какой ток на выходе у 595 в схеме DSC1? Автор-создатель заложить логику аж с 100мА на выходе… Для чего такой запас?

Не совсем понял вопрос.
Ток на выходе DSС2 определяется нагрузкой после трансформатора.
При сопротивлениях AFIR фильтра 5кОм, ток(“покоя”) протекающий между плечами одного канала - в среднем равен 16мА

Не думаю, что у “создателя” этот параметр был определяющим. Гораздо важнее равнозначность
и скорость переключения из 1 в 0 и из 0 в 1. А так же пороги напряжений перехода из 0 в 1 и 1 в 0 для входящего сигнала(согласование с уровнями 3.3В).
А запас, он, в данном случае, карман не тянет.

Ваша идея состоит в том чтобы например запитать “аналоговую” цифру 8t595й 5ю вольтами?

Сейчас и так 595 записана от 5в. Здесь скорее интерес в том, чтобы разделить/распределить питание цифровой(управляющая логика) и аналоговой(выходные d-триггеры) части сдв. регистра 595. Тем самым снизить токовую нагрузку на стабилизаторы аналоговой ветки питания, а также “отделить” шумы управляющей логики.

Но пока это теория, как и когда оно будет на практике не известно.

Выходной там буфер по типу 1G125, вот его и питаем отдельно от всего, да и по разводке печати 8T595 удобнее

да, был не внимателен, действительно по типу 125ой логики.

Не понятно тогда почему выходная логика потребляет больше входной:


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

Продолжение NAA на SBC. Odroid C2.
Забавное устройство - ARM64. По тестам заметно быстрее RPI и, тем более, BBB (особенно если в качестве диска использовать eMMC)

Сразу обнаружились проблемы - hardkernel (производитель Odroid) поддерживает ядра 3.14 - 3.16. В них поддержки Amanero для DSD Native нет (не включены необходимые патчи для Alsa).

Дистрибутивов то много (Ubuntu, Debian, Volumio, DietPi итд), но все они на этих ядрах. Надеясь на чудо перепробовал все с одинаковым результатом - нет заветного DSD_U32_BE в Altset 2.

Т.к. уже устал от сплошных разочарований с SBC - собрал ядро 3.16 с необходимыми патчами (нужно добавить небольшой кусок кода в файл sound/usb/quirks.c), скомпилировал его и установил. Появился DSD_U32_BE в /proc/asound/Amanero/stream0! :grinning:

Странно, но NAA для arm64 в DietPi запустился с Nice = 0, что приводило к регулярным коротким “свистам” на любой частоте DSD. Я не сразу обратил на это внимание. Когда поставил -10, наконец, все стало идеально!
Загрузка проца 8-10%, артефактов нет на DSD512 (связанные с прошивкой Аманеро - на месте)

Сравнений с NAA на NUC не делал - нужно организовать питание от LPS HDPLEX (купить разъем , нет подходящего) и попробовать rt ядро 3.14.

После этого - сравнение NUC vs Odroid в качестве NAA. Но у же понятно - подход вполне рабочий. :grinning:

UPDATE
В Odroid XU-4 поддержка DSD Native Amanero есть, танцы с бубном не потребуются.

3 лайка

Было бы интересно почитать отзывы о подключении к этому цапу стримера напрямую, вроде Sonore.

Я был счастливым владельцем mRendu ~ 1,5 года. Продал его в конце января 2018. В том числе использовал на DSC 2.5 (DSD256 - 512). У меня были претензии к его совместной работе с Аманеро на DSD512 (это проблема Аманеро, видимо).

В целом - стример на Intel NUC i3 более стабилен, если и уступает mRendu по качеству звучания, то не много.

mRendu - отличное устройство, со “слегка” завышенной ценой (500 - 870 USD в зависимости от версии). Сравните со стоимостью Odroid, RPI, BBB (до 100 USD).

На сейчас искренне считаю, что большинство доведенных до ума (софт, питание) SoC-ов будет не хуже u/mRendu в качестве NAA для HQP.

Rendu - хороший выбор для тех, кому нужно готовое устройство (если нет желания ковыряться с софтом). Мне он на текущий момент совершенно не интересен.

Подчеркиваю, что все это исключительно мое субъективное мнение.