PC -> DAC

[Old Sinner]

Начальная посылка: наблюдая постепенное переползание всех жизненных
циклов на ПЦ, прихожу к неизбежности прикручивания к Оному внешнего ЦАП.
Как я понимаю, ничего хорошего (< $1000) из готового нет. Видимо придется сделать.
Подразумевается не фуф*о типа пцм29хх, а нечто близкое к МАКСИМУМУ.

Видятся лишь две дополнительные проблемы, плавно перетекающие друг в друга: интерфейс и помехи.

Помехи "беру на себя".
Предполагаю SPDIF либо USB либо оба.
Хочу спросить уважаемую аудиторию о целесообразности самодельщины. Быть может,
уже все существует, только я не нашел?
Кто что скажет?

[Nikkov]

Почитал тему на electronix, не увидел ничего, что ограничило бы в качестве звука. Во-первых подключение МИДИ действительно будет геморойно, но это нам и не надо, во-вторых автором использовался синхронный режим передачи, который требует подстройки частоты приемника под частоту контроллера USB (т.е. 1 кГц при помощи ФАПЧ синхронизирует поток), естественно стабильность частоты плохая, джиттер дикий. Я писал про использование асинхронного изохронного режима, в котором скорость передачи данных от компа к приемнику синхронизируется вторым каналом (endpoint). Т.е. если скорость передачи не совпадает, то приемник периодически указывает хосту, что необходимо изменить число отсчетов в кадре. Т.о. обеспечивается постоянство заполнения буфера. (вчера еще раз посмотрел в книжке Гука, там в качестве примера приемного устройства с таким режимом называются дешевые USB колонки без возможности подстройки собственной частоты под частоту маркеров USB, в качестве передатчика CD-payer с кварцевой стабилизацией). Эти режимы должны поддерживаться windows драйвером, т.к. являются частью спецификации USB audio.
Потом примененный TUSB3200 не поддерживает работу выходного I2C порта в качестве слэйва, поэтому реализовать на нем асинхронный режим скорее всего невозможно или, по крайней мере, достаточно непросто. К тому же там очень мало ОЗУ. В LPC2148 пока проблем не видно, кроме естественно программирования.
По поводу SRC в Windows: если поток 44100, приемник ее поддерживает, а 48000 не поддерживает, то конвертации точно не будет.
Вот здесь два примера для отладочных плат на LPC2148

[ZugDuk]

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

Что касается полезных функций и ДУ. Все это уже есть в компе. ДУ прикручивается вообще элементарно. Берется простой фотоприемник, выходной сигнал которого, подается на компорт. Комп декодирует и отправляет команды на софт-плеер. Все программное обеспечение давно написано, отлажено и работает.

Короче TOSLINK надо делать. Точнее у платки должно быть 2 входа:
Коаксиальный SPDIF и TOSLINK. Формат выходного сигнала крутится и вертится как надо средствами SPDIF приемника. За нами остается только решение по асинхронности.

[Gav]

По результатам раскопок TAS1020 и TUSB3200 отправляются лесом, по причине "отсутствия наличия" реальной возможности создать на них нормальное устройство. По крайней мере без PLL или буфера.
Остается Ethernet.
Еще есть мысль "играть" с флэшки, но это не подключение к ПЦ...

TAS1020 можно сделать с внешней синхрой,обвязка минимальна-чего еще надо?

[Nikkov]

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

Что касается полезных функций и ДУ. Все это уже есть в компе. ДУ прикручивается вообще элементарно. Берется простой фотоприемник, выходной сигнал которого, подается на компорт. Комп декодирует и отправляет команды на софт-плеер. Все программное обеспечение давно написано, отлажено и работает.

Короче TOSLINK надо делать. Точнее у платки должно быть 2 входа:
Коаксиальный SPDIF и TOSLINK. Формат выходного сигнала крутится и вертится как надо средствами SPDIF приемника. За нами остается только решение по асинхронности.

По поводу USB - кто делал конкретно? В ссылке на форуме electronix первое упоминание о реальной разработке, все остальное, что я встречал, не шло дальше обсуждений. Про гемороя по уши согласен, но это преодолимо. Про ДУ это все ясно, у меня на PICе давно валяется в столе, это я так упоминал, к слову.
Интересно а откуда будет браться SPDIF? Со встроенной в материнку звуковухе? Тогда мы уже точно ничего путнего не вытащим. С одной конкретной платы, типа упоминаемого ABIT? Или с PCM2902? Или откуда?

TAS1020 можно сделать с внешней синхрой,обвязка минимальна-чего еще надо?

А чем отличается TAS1020 от TUSB3200, кроме того, что снят с производства? И можно пример реализации с внешней синхрой (видел реализацию в связке с SRC4392 на разработочной плате последнего, но особо и не искал).

[Gav]

По поводу USB - кто делал конкретно? В ссылке на форуме electronix первое упоминание о реальной разработке, все остальное, что я встречал, не шло дальше обсуждений. Про гемороя по уши согласен, но это преодолимо. Про ДУ это все ясно, у меня на PICе давно валяется в столе, это я так упоминал, к слову.
Интересно а откуда будет браться SPDIF? Со встроенной в материнку звуковухе? Тогда мы уже точно ничего путнего не вытащим. С одной конкретной платы, типа упоминаемого ABIT? Или с PCM2902? Или откуда?


А чем отличается TAS1020 от TUSB3200, кроме того, что снят с производства? И можно пример реализации с внешней синхрой (видел реализацию в связке с SRC4392 на разработочной плате последнего, но особо и не искал).

TAS1020 у меня есть..

[Nikkov]

TAS1020 у меня есть..

А у меня TUSB3200A
Вообще почитал сейчас на TUSB3200A доку, вот вроде поддерживает она асинхронный режим, вернее даже написано, что
"On-chip adaptive clock generator (ACG) supports asynchronous, synchronous and adaptive
synchronization modes for isochronous endpoints"
и
"The adaptive clock generator is used to generate a master clock output signal (MCLKO) to be used by the codec port interface and the codec device. To synchronize the sample rate conversion of data by the codec to the USB frame rate, the MCLKO signal generated by the adaptive clock generator must be used. The synchronization of the MCLKO signal to the USB frame rate is controlled by the MCU by programming the adaptive clock generator frequency value. The MCLKO frequency is monitored by the MCU and updated as required. For asynchronous operation, an external source can be used to generate a master clock input signal (MCLKI) to be used by the codec port interface. In this scenario, the codec device should also use the same master clock signal (MCLKI)."
Но информации по его программированию очень мало. Реально я нашел только один пример прошивки с исходниками, причем без схемы к которой она сделана.

[Ivanuch]

Nikkov
есть платка на TUSB3200 (внешняя USB звуковая карта ABIT UA10) в ней по I2S зацеплен кодек AKM(не помню сколько) в режиме 5.1
Звук так себе... режим изохронный.
Есть 8кБ(если не ошибаюсь, 24С08) ППЗУ-шка с программным кодом для TUSB3200. В TUSB3200 загрузчик этот код грузит. Этот код я прочитал и пытался дизасемблировать... что-то похоже получилось, но до конца разобраться так и не смог, надоело могу отдать инфу.

http://www.dearhoney.idv.tw/soundcar...UA10/pic07.jpg
http://www.dearhoney.idv.tw/soundcard/usb/UA10/

[Old Sinner]

Потерялась ссылка на студенческую страничку (.edu~ чего-то там), на которой упорный американский студент азиатского происхождения хотел сделать на TAS1020 интефейс с внешней синхронизацией. Жаловался он на потери данных.
В приведенной русскоязычной ссылке, как я понимаю автор тоже не смог сделать девайс с внешним клоком и обошел проблему усложнением конструкции с помощью VCXO.
Это все, что я нарыл. Разумеется, нельзя утверждать, что при достаточном напоре проблема не разрешиться. Все-таки USB-шный вариант самый привлекательный. Однако, в последние 5 лет (с появления микросхемы), - ни-че-го. Не считая кучи изделий на этих МС с внутренним клоком, в т.ч. позиционируемые как профессиональные

[ZugDuk]

студент азиатского происхождения хотел сделать на TAS1020 интефейс с внешней синхронизацией. Жаловался он на потери данных.
В приведенной русскоязычной ссылке, как я понимаю автор тоже не смог сделать девайс с внешним клоком и обошел проблему усложнением конструкции с помощью VCXO.
Это все, что я нарыл. Разумеется, нельзя утверждать, что при достаточном напоре проблема не разрешиться.

Теоретически (не практически) проблема решаема. Но все кто пробовал - ни у кого не вышло. Даже в промышленных устройствах вы нигде такого не встретите. Если требуется внешняя синхра, то используется FireWire интерфейс. Принципиальное его отличие от USB в том, что у него есть понятие прерывание, по своей природе близкое к нормальным. (клава, мышка и т.д.) По этому в этом случае работа с внешней синхрой возможна.
USB контроллеры, как вы уже могли заметить, тоже поддерживают внешнюю синхронизацию, но там она сделана для Bulk режима. Для работы с внешними HDD. Но это далеко не наш случай.

[Nikkov]

есть платка на TUSB3200 (внешняя USB звуковая карта ABIT UA10) в ней по I2S зацеплен кодек AKM(не помню сколько) в режиме 5.1
Звук так себе... режим изохронный.
Есть 8кБ(если не ошибаюсь, 24С08) ППЗУ-шка с программным кодом для TUSB3200. В TUSB3200 загрузчик этот код грузит. Этот код я прочитал и пытался дизасемблировать... что-то похоже получилось, но до конца разобраться так и не смог, надоело могу отдать инфу.

А не изохронных не бывает, но изохронных 3 варианта. А в случае с ABIT UA10 я думаю и не это определяет качество. Ну инфа в любом случае пригодится, давай в личку.

Потерялась ссылка на студенческую страничку (.edu~ чего-то там), на которой упорный американский студент азиатского происхождения хотел сделать на TAS1020 интефейс с внешней синхронизацией. Жаловался он на потери данных.
В приведенной русскоязычной ссылке, как я понимаю автор тоже не смог сделать девайс с внешним клоком и обошел проблему усложнением конструкции с помощью VCXO.
Это все, что я нарыл. Разумеется, нельзя утверждать, что при достаточном напоре проблема не разрешиться. Все-таки USB-шный вариант самый привлекательный. Однако, в последние 5 лет (с появления микросхемы), - ни-че-го. Не считая кучи изделий на этих МС с внутренним клоком, в т.ч. позиционируемые как профессиональные

Что в русскоязычной ссылке говорилось про асинхронный режим не помню, автор жаловался на кривую реализацию адаптивного режима в Windows - это когда USB передатчик должен подстраивать свою частоту под приемник.
Отсутствие информации - это не признак, по крайней мере кучи фирм делают на ней платы пусть и в синхронном режиме, а где эта информация? Отсутствие любительских конструкций связано прежде всего со сложностью реализации, гораздо проще сделать все на PCM2XXX и радоваться, ну и любителям трудно с техаских инструментов выудить хоть что-то кроме даташитов.
С точки зрения программиста в TUSB3200 есть очень большой недостаток - памяти всего 256 байт, отсюда может и были проблемы с потерей данных. В том же LPC2148 ее 32 кБ + 8 кБ для DMA. Сложность реализации протокола USB абсолютно одинаковая, но потенциально с LPC проблем должно быть меньше. Правда их не шлют сэмплами .
Вообще, все это я к тому, что быстро, просто и хорошо не получится, ни с USB, ни с чем другим, надо копать. Но с USB хоть есть вариант без разработки своих драйверов, а с другими варантами (PCI Fireware Ethernet) придется еще и это делать. Если найдутся желающие, могу принять участие в разработке, правда, ни приборами, ни оборудованием не обременен , раньше хоть на работе была возможность, а сейчас и того нет.

Nikkov добавил 09.08.2006 в 14:48

Теоретически (не практически) проблема решаема. Но все кто пробовал - ни у кого не вышло. Даже в промышленных устройствах вы нигде такого не встретите. Если требуется внешняя синхра, то используется FireWire интерфейс. Принципиальное его отличие от USB в том, что у него есть понятие прерывание, по своей природе близкое к нормальным. (клава, мышка и т.д.) По этому в этом случае работа с внешней синхрой возможна.
USB контроллеры, как вы уже могли заметить, тоже поддерживают внешнюю синхронизацию, но там она сделана для Bulk режима. Для работы с внешними HDD. Но это далеко не наш случай.

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

[ZugDuk]

автор жаловался на кривую реализацию адаптивного режима в Windows - это когда USB передатчик должен подстраивать свою частоту под приемник.

Да. Именно это есть главная проблема. Это связано с тем, что только комп является инициатором всех дел касающихся пердачи данных по USB. По этому, чтобы реализовать прерывание, он должен постоянно опрашивать приемник, а не хочит ли тот еще данных. Но винда не выставляет этому процессу опроса, достаточного приоритета. Да и вообще, если даже заставить выставлять таки приоритет, то получится, что комп только и будет заниматся тем, что опрашивать USB. Пойдет тормозня на все остальное. Причины такого поведения видимо кроются в части того, что этому процессу опроса и обработке такого программного прерывания не было уделено должного внимания в мелкософте. Они обещали доделать данный режим в longhorn (vista), но лично я больше чем уверен, что нифига они не сделают. Да это и не нужно, т.к. есть FireWire

[Old Sinner]

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

Бесспорно. Рано или поздно, данные появяляются, нужно только буфер. У LPC2148 дожно хватить с запасом.

Рассматриваем только 44.1?

[Nikkov]

Да. Именно это есть главная проблема. Это связано с тем, что только комп является инициатором всех дел касающихся пердачи данных по USB. По этому, чтобы реализовать прерывание, он должен постоянно опрашивать приемник, а не хочит ли тот еще данных. Но винда не выставляет этому процессу опроса, достаточного приоритета. Да и вообще, если даже заставить выставлять таки приоритет, то получится, что комп только и будет заниматся тем, что опрашивать USB. Пойдет тормозня на все остальное. Причины такого поведения видимо кроются в части того, что этому процессу опроса и обработке такого программного прерывания не было уделено должного внимания в мелкософте. Они обещали доделать данный режим в longhorn (vista), но лично я больше чем уверен, что нифига они не сделают. Да это и не нужно, т.к. есть FireWire

Про реализацию в Windows ничего не скажу еще не смотрел. Но спецификация для асинхронного режима говорит примерно следующее:
для организации обратной связи заводится еще одна конечная точка, для которой указывается как часто ее надо опрашивать и она указывает как нужно изменить поток, чтобы избежать потерь данных. Т.е. опрашивать можно хоть раз в секунду, лишь бы размер буфера позволял избежать опустошения или переполнения. Для изохронных режимов компу вообще не надо опрашивать приемник для того чтобы узнать хочет он данных или нет, конечная точка при инициализации сообщает какую скорость ему необходимо поставлять. Синхронный, асинхронный и адаптивный режимы определяют как при обмене эта скорость будет подстраиваться. По поводу прерывания звука при дерганьях мыши и т.п. - частично это зависит от загруженности шины, частично от загруженности процессора. Второй вариант вызывает прерывание звука на ВСЕХ звуковых карт, включая ISA и PCI, первый можно исключить посадив карту на отдельнай USB контроллер, благо их на PC чаще всего более одного.

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

Бесспорно. Рано или поздно, данные появяляются, нужно только буфер. У LPC2148 дожно хватить с запасом.

Про размер буфера в TUSB3200 тоже не одназначно - при использовании в режиме DMA используются буфера конечных точек, а там запас есть. А 256 байт остаются на программный PLL, управление кодеками и ЦАПами, управление скоростью обмена. Но у TUSB3200 еще один и большой недостаток - отсутствие отладочных интерфейсов. Наиболее реальный метод разработки под эту м/сх - использование отладочной платы, имеющей возможности внутрисхемной эмуляции. Может поэтому и не появилось любительских конструкций на TUSB3200.

Рассматриваем только 44.1

Я думаю ориентироваться надо, в первую очередь, на 44100, т.к. основным источником качественного звука пока остаются CD.

Nikkov добавил 10.08.2006 в 06:30
По поводу Firewire:
http://www.oxsemi.com/oxford/documen...t/OXFW970.html
но где его купить? Мы покупали образцы PCI и CF интерфейсов этой фирмы, но потом долго писали в какой стадии наш проект. Ну и информация от них давалась только после подписки о неразглашении.

[Old Sinner]

А 256 байт остаются на программный PLL, управление кодеками и ЦАПами, управление скоростью обмена.

Да-да, на переменные для управления всем, включая буфер всего 256 байт.

Я думаю ориентироваться надо, в первую очередь, на 44100, т.к. основным источником качественного звука пока остаются CD.

Я согласен

По поводу Firewire:
http://www.oxsemi.com/oxford/documen...t/OXFW970.html
но где его купить?

Кажется, из рекламы на сайте не следует, что эта штука подойдет.

Мы покупали образцы PCI и CF интерфейсов этой фирмы, но потом долго писали в какой стадии наш проект. Ну и информация от них давалась только после подписки о неразглашении.

Вот-вот. Говорил со знакомым, писавшим для "обоих концов" Firewire. Одни проклятия по поводу подобной переписки

Скачал все, что нашел для LPC2148.
Предлагаю обсудить способ реализации выходного потока потенциального устройства. Дело в том, что из примеров для Keil и IAR по-моему не следует, что эти решения возможны при внешней синхронизации.
Может, я что-то упустил?

[escapist]

Хочу спросить уважаемую аудиторию о целесообразности самодельщины. Быть может,
уже все существует, только я не нашел?
Кто что скажет?

Существует, только никому не нужно.

Здравствуйте!
Сюда меня позвал "aal" на форуме IXBT. Иногда читаю болтовню DIYеров на эти темы. Забавно, что черт знает сколько перемалывают jitter, FIFO итд итп. У меня давновсе работает. Заапгрейдил только серию 1533 на 74HC и 74AC. Все сделано просто как лопата. S/P-DIF приемник поключен к сдвиговому регистру, выходы регистра подключены к ОЗУ 32Кх8, аОЗУ ко второму регистру, который преобразует опять в последовательный формат. Управляет всем проц. Он же рулит VCXO, очень-очень медленно иаккуратно. Ни фига не влияют никакие источники сигнала. Ржу над владельцами транспортов за тыщи баказоидов. Нужно только, чтобы у источника кварц был более-менееточным, чтобы захват произошел. Один только раз попался CD-ROM Гунсмас 20-ти или 24х-скоростной, у которого частота S/P-DIF изменяется раз в500, пропорционально частоте вращения диска.

[Nikkov]

Да-да, на переменные для управления всем, включая буфер всего 256 байт.

Я согласен

Кажется, из рекламы на сайте не следует, что эта штука подойдет.

Вот-вот. Говорил со знакомым, писавшим для "обоих концов" Firewire. Одни проклятия по поводу подобной переписки

Скачал все, что нашел для LPC2148.
Предлагаю обсудить способ реализации выходного потока потенциального устройства. Дело в том, что из примеров для Keil и IAR по-моему не следует, что эти решения возможны при внешней синхронизации.
Может, я что-то упустил?

Да чтобы с примерами разобраться надо попотеть, я еще не смотрел с пристрастием. В примерах вообще не синхронизируемые изохронные, т.е. самый примитив, но хоть что-то. Я вообще думал так: организуется выходная изохронная конечная точка с DMA и асинхронным режимом подстройки, заводится вторая изохронная точка обратной связи для регулировки скорости обмена. Выходной порт проще всего в I2C в слайве, либо по внешним прерываниям параллельно по байтам, смотря что проще в дальнейшем привести к понятному ЦАПам формату.
Алгоритм примерно такой: выделяется некий размер буфера, гарантированно обеспечивающий отсутствие опустошения или переполнения при максимально возможной разности частот передатчика (USB) и приемника (ЦАП) на некотором промежутке времени t. Данные на выход поступают с некоторой задержкой относительно поступления данных на вход и задача обратной связи - регулировкой скорости передачи обеспечивать в среднем на интервале времени t постоянное число отсчетов в буфере.
Для меня принципиальный вопрос один: как с поддержкой изохронных асинхронных аудио устройств в Windows? Вот с ним бы надо разобраться. Для LPC я рисую плату, аналог Olimex, JTAG по типу Wiggler, но сейчас дома ремонт делаю, так что попробовать смогу не раньше чем через пару месяцев.

Существует, только никому не нужно.

Здравствуйте!
Сюда меня позвал "aal" на форуме IXBT. Иногда читаю болтовню DIYеров на эти темы. Забавно, что черт знает сколько перемалывают jitter, FIFO итд итп. У меня давновсе работает. Заапгрейдил только серию 1533 на 74HC и 74AC. Все сделано просто как лопата. S/P-DIF приемник поключен к сдвиговому регистру, выходы регистра подключены к ОЗУ 32Кх8, аОЗУ ко второму регистру, который преобразует опять в последовательный формат. Управляет всем проц. Он же рулит VCXO, очень-очень медленно иаккуратно. Ни фига не влияют никакие источники сигнала. Ржу над владельцами транспортов за тыщи баказоидов. Нужно только, чтобы у источника кварц был более-менееточным, чтобы захват произошел. Один только раз попался CD-ROM Гунсмас 20-ти или 24х-скоростной, у которого частота S/P-DIF изменяется раз в500, пропорционально частоте вращения диска.

Действительно, что мы тут делаем А откуда данные на SPDIF приемник попадают? С выхода CD-ROM?

[aal]

escapist
А какой VCXO запользывал. Может Кусок схемы кинешь сюда?

Насчёт армов - атмел сейчас начал выпускать Sam7X. На борту USB 1.1, Mac Ethernet. Памяти много. Цена соизмерима. Прошивать можно через USB.
Я больше склоняюсь к TCP/IP через Ethernet. Может получится меньше проблем в проце - ну а в виндах плугин к винампу...
Производительности должно хватить на распаковку "обезьянки" - исходники ведь открытые
Даже если вы остановитесь именно на USB - проц всё равно более интересный.

[Nikkov]

escapist
А какой VCXO запользывал. Может Кусок схемы кинешь сюда?

Насчёт армов - атмел сейчас начал выпускать Sam7X. На борту USB 1.1, Mac Ethernet. Памяти много. Цена соизмерима. Прошивать можно через USB.
Я больше склоняюсь к TCP/IP через Ethernet. Может получится меньше проблем в проце - ну а в виндах плугин к винампу...
Производительности должно хватить на распаковку "обезьянки" - исходники ведь открытые
Даже если вы остановитесь именно на USB - проц всё равно более интересный.

Нее, с Ethernet проблем еще больше. Реально придется ставить какую-то OS на проц, а может получится так, что производительности и памяти хватит только на поддержку стека. Хотя можно посмотреть, что есть из устройств на эту тему с RTP протоколом.
Если протокол RTP (см, например http://book.itep.ru/4/44/rtp_4492.htm, то плагин к WinAMP уже есть. Ethernet вообще-то самый красивый вариант, но и самый затратный в аппаратном смысле.

[aal]

Так есть простые оски с встроенным стеком - посуществу остаётся написать задачу... Для меня это самый интересный вариант.А память внешнюю с вероятностью 70% прикручивать придётся...
Для 44.1 можно запользывать wiznet - 3м байта при быстром проце по udp. Может и по tcp не намного меньше будет.

[escapist]

@Nikkov Действительно, что мы тут делаем

Не обижайтесь, такие разговоры действительно уже много лет идут,это факт. Я обычно diyaudio читаю. Там это как молитва. Прада, недавно человек с ником foo чуть было не начал что-то делать, но потух все-таки.

@Nikkov А откуда данные на SPDIF приемник попадают? С выхода CD-ROM?

Да с любого S/P-DIF. Многие старые CD-ROM читают гораздо лучше любых транспортов. У меня сейчас источником служит звуковуха на C-media.


@aal А какой VCXO запользывал. Может Кусок схемы кинешь сюда?

VCXO Crystek. Думаю, перенести подстройку в обиженную зздесь UA-11, чтобы избавиться от него. Схема в электронном виде не существует, нотам все просто, кроме программы. CS8412 - регистр - ОЗУ - регистр - выход на реклок. Помимо этого, 14шт. рассыпухи 74HC/AC для всяких служебных нужд. Печатной платы нет, все на МГТФ.