alexdsp

Процессор замечательный, понимаю, 1 Мрад - это круто, но вики сообщает следующее - "Стоимость RAD750 сравнима со стоимостью RAD6000 и начинается от 200 тыс. долларов США (в ценах 2002 года)", что кагбэ несколько неприемлемо...

Интересно. Цены примерные на ATF697FF подсказать можете? Ну и на ATF697F тоже за компанию было бы неплохо узнать.

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

Хотелось бы спросить насчёт SmartFusion2. Что там будет с внутренним хард-ядром ARM? Оно тоже будет аппаратно затроировано на уровне триггеров , как и остальная логика? Просто очень нужно SEU защищённое процессорное ядро живучее с TID 100 крад или лучше. Можно ли уже отлаживаться на SmartFusion2 или Igloo2 с последующей миграцией на радхард версию? Опять, же... если она ещё будет эта версия... и когда. Сейчас встаёт проблема выбора. Видел отчёты реальных людей с тестами, где RTPA3 уже от 20 крад физически дохнут. Накрывается charge-pump цепи, да так, что уже невозможно ни стереть, ни пепепрошить. RTPA3 отпадает. ProASICplus устарел, да и мало подходит для проекта. По SmartFusion2 и Igloo2 радиационных данных пока не нашёл. Меня склоняют к индустриальному Virtex-у, и аргументов против у меня уже не хватает. В идеале, если бы индастриал Igloo2 переносили хотя бы 100 крад дозы, имело бы смысл поднапрячься с софт-троированием стороннего софт-ядра и т.д...

На тему набрёл поиском. Хочу попробовать Quectel L20, а как-то с документацией в сети оказалось негусто. Насколько я понял, там есть OpenCPU, хотелось бы с SDK тоже разобраться досконально. Подскажите пожалуйста, где находится нормальная документация и всё остальное? Сайт Quectel как-то подозрительно пуст...

Очень просто, дело в том, что в циклоне выходы LVDS имеют "неправильный" уровень и должны корректироваться резисторами, это в соотв. аппнотах написано, надеюсь они у вас есть, иначе вообще LVDS работать не будет. В вашем случае, я бы просто назначил на рабочие выходы (LVDS97n, LVDS96p при LVDS) тип LVCMOS, а в самом проекте, рабочий сигнал подал на тот вывод, который в LVDS был прямым, а на второй диф. вывод подал бы инверсию, и всё. Это абсолютно эквивалентно и никак не повлияет ни на что. Другое дело, если бы вы ошиблись в разводке диф. входа LVDS приёмника, тут бы уже ничего нельзя было исправить.

А Freescale не рассматривали? Например MPC5200B. 400MHz, double precision FPU и прочее. Не DSP, но всё же PowerPC, да и энергопотребление вообще скромное. Я лично с ним дела не имел, но когда-то бегло просмотривал документацию. На мой взгляд очень достойный чип. Интересно ваше мнение.

KPAH Большое спасибо за ссылку. Очень документ порадовал (хотя такой метод генерации синуса я знал и раньше). 0FF/2 А есть ли ещё что-нибудь в этом же духе, т.е. в виде справочника по разным методам, алгоритмам и прочее?

Посмотрел бегло AVC. Впечатление такое, что разработчикам стандарта очень хочется перейти на DWT, но вот начальство не позволяет :)) Этот метод похож на блочный DWT 16х16, но только почему-то там опять DCT :). DWT же ЛУЧШЕ! Правда, только в случае неиспользования RLE. Там всякие "зигзаги" не прокатят. Видимо поэтому этот вариант и не прошёл. Прежде чем перейти на DWT схемы, я сделал кодек типа JPEG для BF на DCT. Потом "тупо" заменил DCT 8x8 на блочный вэйвлет Хаара 8х8. Так, ради смеха. И о чудо! При равном битовом потоке, визуально картинка стала лучше, не так сильно "рассыпается" на "квадратики". Точнее, эти квадратики имеют не такую ярко выраженную блочность, так как они не все размера 8х8, а встречаются 4х4, 2х2. Из таких кирпичиков изображение и "мостится". Это при сильном квантовании. А при слабом - лослесс он и есть лослесс на вид :) Весь прикол в том, что при вычислении вэйвлета Хаара не происходит ни одного умножения, только сложения и вычитания. Беда только в том, что тут оказывается малоэффективен RLE, другие свойства у преобразования. Потом я стал экспериментировать с другими вэйвлетами, более устойчивыми к ошибкам квантования, а потом уже придумал полноэкранную схему с низким трафиком. Так вот, на мой взгляд, при прочих равных условиях, у DCT нет ни малейшего шанса составить конкуренцию DWT. При прочих равных. Другое дело, DWT нужно брать конечно же не Хаара, а что-нибудь из высоких порядков Добеши или аналогичных биортогональных. Другое дело, на PC их считать довольно трудно и по времени вычисления они проигрывают схемам с DCT. Может поэтому их и избегают, а может ещё по каким причинам сложно поддающимся анализу... На DSP картина выравнивается. Быстрое DWT намного более регулярный алгоритм, чем быстрое DCT. Для быстрого вычисления DCT существует много разных схем - одна "корявее" другой. По крайней мере, на BF я просто запарился с этой несимметрией. Для вычисления DWT применяется (в реальных устройствах) в основном две схемы - лифтинговая и дерево Молла. В общем - дело вкуса. У каждой из них есть свои преимущества. У лифтинговой - меньше умножений, но некоторая кривизна присутствует. Дерево Молла - для современных DSP очень гармоничная и гибкая схема (IMHO). Я просто хочу ещё раз сказать, что я имел возможность сравнить обе технологии (DCT vs DWT) при равных условиях. И результат сравнения был сильно не в пользу DCT. Единственный аргумент "против" - это то о чём вы уже упоминали: "нестандартность". Против этого уже не попрёшь, конечно...

Тут я вас прекрасно понимаю. Но мы то как раз разрабатываем законченное изделие, а не технологию. Продаваться будет изделие, поэтому мы вправе навязать своё решение потребителю, благо оно не уступает продукции конкурентов. И блэкфин был выбран как раз из-за суммарной дешевизны платформы. Конкуренты, в принципе не могут сжимать 704x576 - 25 fps в многоканальном режиме. У них применяются аппаратные кодеки, рассчитанные на ограниченное количество каналов (1-4), и весьма ограниченный fps и (видимо) плохо поддающиеся масштабированию. Я (скоро) смогу. То есть 20 fps уже есть. Была ревизия алгоритма - будут и 25 fps. dryadae Специфика таких дизайнов в FPGA в том, что эти ваши умножители будут очень жёстко привязаны к своей функции внутри блока и будут быстро расходоваться на каждое мало-мальски необходимое умножение, или вы полностью утонете в мультиплексорах и связанных с ними регистрах конвейеров. Плюс ОЧЕНЬ высокая сложность такой реализации. Есть немало проектов видео-сжатия в FPGA , бодро начавшихся несколько лет назад и продолжающихся до сих пор в стадии пре-альфа. И пока вы будете смаковать потенциальную, гипотетическую возможность разработки HDTV кодека на S3E или Stratix-е - корейцы при помощи китайцев испекут ASIC на 90 нанометрах. И куда вы потом денете ваш дизайн, да ещё жестко привязанный к вашим 20 умножителям и архитектуре Spartan? Уж не говоря о том сколько времени вы будете его делать. Понятное дело, такое же можно сказать и обо мне. Мол тоже, к блэкфину привязался - неотвяжешься. Да, именно так, но есть и отличие: 1) всё уже сделано и отлично видны перспективы развития моего кодека. Перспективы хорошие. Частоты процессоров растут, а потребление падает. Потом. Сжатие я сделал в одиночку за полгода. Такой же проект на FPGA я даже не знаю, не возьмусь оценить сколько времени у меня уйдёт, несмотря на мой очень немаленький опыт программирования FPGA. (Правда, я использую Альтеру) Я даже не смогу гарантировать конечный результат, который бы был коммерческим. Возможно, (такое нынче встречается) у вас очень сильная команда FPGA дизайнеров, каждый из которых по совместительству хороший математик, и вы справитесь. Возможно. Всякое бывает. На нашей фирме (меня ещё тут не было) тоже был хороший FPGA дизайнер, и он не справился. А начиналось всё очень радужно. Оценки были как у вас. Звучали слова "умножители", "мегагерцы" и прочая патетика, но проект не поместился в нужную микросхему. Никак. А микросхема бОльшего размера не помещалась в бюджет разрабатываемого девайса. Тоже никак. Ну... можно было (что и было предложено) подождать новой серии спартанов. Начальство эту новость восприняло без энтузиазма. А делался всего-навсего обыкновенный JPEG. Самое разумное для вас - это поискать аналогичные решения в предложениях конкурентов, чтобы не оказаться в такой же ситуации. Чтоб было понятно - а реализуемо это в принципе или нет? Когда я начинал выбор платформы, я перелопатил много информации в интернете об аналогичных продуктах: в основном - библиотеки, где обычно сказано какие параметры достигаются, какой fps при каком разрешении, на какой тактовой и прочее... Это мне сильно помогло. Хотя, я тоже сильно рисковал, так как исходил из предположения, что всё равно смогу сделать немного лучше. :) Вот вы сами как себя ощущаете когда произносите подряд три слова: DCT, RLE, Huffman? :) Технологии - то ведь отсталые, отсталее некуда. Да и Хаффман-то небось статитечский... И никакие примочки их уже не спасут IMHO.

Зато результат достигается быстро и недорого в сравнении с FPGA. Опять же, где есть такие FPGA стоимостью $25, которые делают 4 одновременно 16х16=>32 MAC-а на частоте 600МГц ? А ведь блэкфин - это самое что ни есть бюджетное решение. А ведь есть ещё Tigersharc, есть продукты от TI типа DM642 и проч...(по TI я не спец.), и в этом случае изделие на FPGA совсем делается неконкурентным (может быть, разве что в военном применении, где цена вообще значения не имеет). Ну... ещё вариант, если вы решили печь ASIC. Тогда такое стремление можно оправдать. Ещё раз зацитирую... Это с чего вы так решили? Ну... тогда следуя аналогии получится, что bf53х - только одну!? :) Посмотрите в сторону инструкции процессора SAA. Эта инструкция за один такт обрабатывает 8 пикселей. В двух ядрах - их соответственно будет 16. И вообще, нахрена козе баян, а сжатию - МЕ? Даёшь полноэкранные трансформации! Нет блочным алгоритмам! Урррааа! :) В общем... делать сжатие на FPGA вы меня не уговорили ;)

На ассемблере для blackfin? В режиме сжатия дающее 25 fps (хотя бы CIF)?

Арифметика такая. Сначала полукадры пишутся при помощи DMA в SDRAM. Полукадр занимает 1440*288=414720 байт Теперь трафик SDRAM самого алгоритма. Для ч/б компоненты при разрешении 704*288 полный трафик SDRAM алгоритма составляет примерно 550 Кб из которых 405 - это собственно, чтение этого полукадра обратно из SDRAM. Неплохо, правда !? :)) Да... добавлю. Везде, внутри каждого банка SDRAM доступ ведётся ТОЛЬКО по последовательным адресам. Никакого рандома! То есть, будем считать, что про пречарджи и рефреши можно временно забыть :) Примерно столько же трафика уйдёт на Cb и Cr компоненты. То есть, цветной полукадр "скушает" 405(PPI DMA) + 550(Y) + 550(Cb,Cr) = примерно 1.5 Мбайт трафика. При сжатии обоих полукадров цифра удваивается. То есть, сжатие 704х576 в цвете порождает трафик 3 Мбайта. Что же нам может предложить самый "хилый" из блэкфинов bf531? SDR шину шириной 16 бит и SCLK=133МГц => 266 Мбайт/сек что в конечном итоге даёт 266/3 = 88 fps Ну, в реальности, всё таки будут потери на переходы и смены банка, пречарджи и рефреши и пр. Думаю, что тут мой предел по трафику при PAL video 704х576 будет где-то в пределах 50 fps, а мне всего-то нужны какие-то 25 :) В общем, в железе так оно и есть. Я утилизирую меньше половины пропускной способности шины и полностью упираюсь в ядро процессора.

Арифметический кодек - не бинарный MQ :) Наиболее близким аналогом является range-coder , но только внешне. Кодер полностью сделан и оптимизирован для процессоров BF. Да, кодер адаптивный. Контексты расчитывает сам. Ещё раз повторюсь. Целью было не "победить" JPEG и остальных, а сделать "много" кадров в секунду при прочих адекватных характеристиках. Я прекрасно понимаю, что может быть другие алгоритмы в чём то и превосходят мой, но по скорости на семействе блэкфинов они и рядом не лежат с моим. Вот и всё. :) Да. Полная лицензионная чистота - залог крепкого экономического здоровья :) Позже. Надо посчитать. Но если навскидку, то сейчас я далеко не упираюсь в память. При 60 fps на цветном 352х288.

Декодер, разумеется существует, но по тем же причинам выложить я его не могу. Хотя, могу сразу оговориться, что в рамках общей радужной картины с моим кодеком, декодирование - самая ресурсоёмкая часть. К сожалению, разжатие примерно втрое медленнее чем сжатие благодаря специфике арифметического кодирования. Но так как разжатие преимущественно осуществляется на PC, то высокая тактовая частота PC-шных процессоров делает своё дело исправно. И там и тут реалтайм достигается. Именно. БОльшая часть. Даже при сжатии. При разжатии просто значительно бОльшая часть. БОльшая не только по вычислительному ресурсу, но и по сложности вычислений. Существенно сложнее чем все эти вэйвлеты, пускай даже самые хитрые.

Да, я нашёл способ делать полноэкранный вейвлет (любых порядков) БЫСТРО и не упираться в трафик памяти (в разумных пределах конечно), поэтому могу себе позволить отказаться от блочных алгоритмов вообще. Несимметрия по вертикали и горизонтали решается очень просто. Автоматически. Просто правильно строится дерево Молла и всё. В результате, после первой итерации пространственные частоты выравниваются. Видимо, поэтому это я как проблему и не воспринял. Единственное для чего нужен зигзаг, так это для адекватной работы RLE. И ВСЁ! Энтропийному кодеру RLE не нужен, и более того в предельном случае, последовательность обхода вообще не важна. Весь потенциал технологии раскрывается в процессоре BF561, у него и шина 32 бита, и два ядра на 600 Мгц.... красотааа! :) На самом деле они актуальны. Но также актуально сделать РЕАЛЬНУЮ ВЕШЬ которая превосходит конкурентов по многим показателям. По энергопотреблению мы уже сейчас ДАЛЕКО обходим продукцию конкурентов, здесь блэкфин очень хорош. Трафик уменьшить тоже можно, но НЕЛЬЗЯ урезать функционал и качество в угоду этому трафику. Везде есть разумный компромисс. Это всё правильно, но BF просто НЕ МОЖЕТ породить больше данных на шине, также как и принять их, какая бы быстрая DDR ни была. Моё мнение здесь однозначно, при правильном программировании встроенного контроллера SDRAM, результат будет выше чем с внешними примочками. У BF хорошая шинная архитектура, позволяющая довольно свободно манипулировать внешним трафиком, обеспечивая максимальную утилизацию шин, и эту ситуацию можно только ухудшить.

И тут есть мааленькая неточность, ну.. обманул немного. Контроллер SDRAM у BF так устроен, что он МОЖЕТ формировать бёрст на нечётное слово, но на большее он не способен. То есть - это даёт выигрышь при чтении двойного слова против двух чтений слов в отдельности. Но это так... будем считать, что не умеет. Улыбнуло :) Для полноэкранной трансформации (каковой является применяемый у меня вэйвлет) не нужно делать оценку движения. Она нужна только в блочных алгоритмах, где размер исследуемой области очень мал и нужно найти корелляцию между этими областями. У меня же трансформация ведётся по всему видео массиву, а не по отдельным его кусочкам типа DCT 8х8. Для примера, алгоритм спокойно умещается во внутреннюю память BF531 + внешняя SDRAM 16Мб. Внешняя память ДОЛЖНА быть 4-х банковой. По остальным вопросам, кратко, так как в общем-то в них и заложен ответ: прерывания задействованы самым оптимальным образом, питание - гибридное, сеть, но есть переключение на батарею. ОЧЕНЬ низким битрейт быть у меня не может в силу нескольких причин. Сами понимаете, мой алгоритм был создан мною исходя из конкретных особенностей архитектуры процессора для обеспечения производительности в первую очередь. То есть - я должен сжимать CIF не особо напрягаясь. Затем - я должен также сжимать и полный PAL (скоро будет 25 fps). И при всём при этом иметь хорошее качество картинки (конкурентное) и всё такое прочее... Поэтому я вынужден был искать компромиссы и придумывать новые эффективные методы. От DCT я отказался. Правда, написал кодек для BF. От межкадровогого сжатия - тоже, так как это планировалось сделать в следующем этапе работы (было бы слишком сложно и непредсказуемо делать всё и сразу). В данный момент на CIF(352x288 в цвете) как правило размер кадра при довольно сильном сжатии и как следствие - среднем качестве картинки не может быть меньше 5 кбайт (я это конечно могу изменить, но не буду, так как для нас это приемлимо). Разумеется, алгоритм полностью управляемый параметрически, я могу задать даже режим CBR указав желаемый объём кадра и система будет пытаться выполнить мои требования в реалтайме. То есть это мегабит в секунду. В будущем будет и межкадровое сжатие, там будет поток меньше на "спокойных" сценах, но не сейчас. В проекте очень много и других составляющих кроме сжатия - сеть, жёсткий диск и прочее... Но даже сейчас получилось лучше чем JPEG. Как любой энтропийный алгоритм - к ошибкам критичен. Защищать нужно на транспортном уровне, что мы и делаем. Сжимаются два смежных полукадра 704х288 независимо, и как следствие - нет никакого интерлейсинга (если конечно правильно обратно выводить на экран) :) Про высокую верт. частоту не понял юмора что то... :) Зачем с ней бороться-то? С какой частотой кадры приходят, с такой их и жмём. Если не успеваем, то поступаем наиболее оптимальным образом. Грамотно пропускаем полуполя, на фоне запускаем новый захват, синхронизируемся на первое поле и так далее и тому подобное... Более чем реально, но... PAL - это 25 fps :) В нашем проекте 9 процессоров, 32 PAL камеры и прочее, и если сложить весь трафик.....уухх :)) Ничему не противоречит, но и ни зачем не нужна. DDR-то к ней не прикрутишь...увы...

Stanislav Разумеется кодек полностью нестандартный, но и не "open source". А по поводу картинок, то соотношение размер/качество примерно эквивалентно тому что получается при JPEG сжатии благодаря тому, что у меня нет возможности на сложное статистическое оценивание материала в реальном времени, в отличие от JPEG кодеков на PC со значительно более толстыми процессорами. Но благодаря более прогрессивной трансформации и энтропийному сжатию (против Хаффмана у JPEG) ситуация выправляется. Разве что характер искажений при сильном квантовании у нас разный. JPEG рассыпается "квадратиками" (DCT), а у меня появляется "акварельность", более сильная размытость картинки (fullscreen wavelet). Психовизуально - второй вариант лучше. vetal В целом, всё верно, но только к сожалению, у современных блэкфинов нет контроллера DDR, а применение моста ASYNC -> DDR на FPGA приведёт к "уполовиниванию" пикового трафика, так как обмен по асинхронной шине ведётся (эффективно) на половинной частоте шины. А DDR как раз и хорош этим самым "пиковым" трафиком, ради чего весь "сыр-бор" разгорелся.

Результаты впечатляют. Скажите, а межкадровую обработку делать не планируете? Планирую, но уже в третьей ревизии. Помимо сжатия в проекте ещё очень много составляющих которые нужно реализовать. А по сжатию, надо лишь натянуть режим 704x576 в цвете до 25 fps, и это будет карашо! :)

dryadae Добавлю немного своего мнения. Для начала уточню: 1) Я делал собственные алгоритмы сжатия для BF. 2) Они работают в железе. По поводу подключения внешней DDR через FPGA. Если вы задумали это делать через асинхронную шину, то сразу надо понимать то, что весь обмен по ней происходит на эффективной частоте SCLK/2 (так как вствляется один такт принудительного "setup"), то есть пиковый трафик будет вдвое меньше чем на SDRAM. Как уже тут говорили, BF не умеет делать "burst" при чтении, но если всё заранее спроектировать, то чтение можно перевести на DMA. Вот пример моей системы, как образец что может BF, а чего не может. ADSP-BF532 393 MHz, внешняя SDRAM 131 MHz Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком. Видео и производительность: Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны Сжатие цветного 704x576 примерно 20 fps Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам) Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах. При всём этом хочу напомнить, что этот процессор имеет всего-лишь 16-разрядную шину и не умеет делать "burst" по чтению. Видите, на самом деле всё не так уж и страшно :)

Опять же, можете поконкретнее рассказать о ваших предпочтениях? Кит посоветовать несложно, ну вот например: ADDS-BF537-EZLITE Супер Кит! Правда хорошо посоветовал?! Большего и пожелать-то трудно, но.... Вы меня конечно же спросите, а что такое ADSP? А как его программировать, и пошло поехало... В любом случае, я точно вам скажу, что лёгкого старта не получится, и всё равно ПРИДЁТСЯ изучить что же такое этот Ethernet. Поэтому, для начала советую почитать спецификацию на Ethernet, лучшего документа вы не найдёте, плюс книжки. Их масса. То чем пользовался я когда писал свою ethmac корку - Тим Паркер, Каранжит Сиян "TCP/IP Для профессионалов. 3-е изд" Большая такая книга в твёрдой жёлтой обложке. Издательство "Питер" У. Ричард Стивенс "Протоколы TCP/IP. Практическое руководство" Издательство "BHV" Мягкая обложка в стиле типичном для этого издательства. Обе книжки хорошо дополняют друг друга и очень толковые. Также в интернете есть много открытых исходников IP стеков (lwIP, OpenTCP, uIP и проч.) и плат на микроконтроллерах с Ethernet, их просто море, и гугл здесь лучший помошник.

Решение очень простое. В EE197 прямо об этом и сказано, нужно обнулить lcX (или убедиться что там ноль). r0 = 0; lc0 = r0; lc1 = r0; Дальше можно загружать lcX без всяких задержек чем угодно. Предварительно, разумеется lc0,lc1 сохраняются в удобном месте.

У меня всё решилось подтягиванием RXER резистором к земле. Он ДОЛЖЕН быть нулём при старте. К MDIO я даже не прикасаюсь, всё по дефолту. Сейчас всё работает как положено, пакеты и принимаются и передаются.

adsp-bf532: 400Mhz - core clk 400/3 = 133Mhz - system clk по даташиту на 133 у меня работает без резисторов, правда в 4х слоях. У меня частоты аналогичные, но на шине кроме SDRAM ещё и FPGA торчит. Резисторов нет (только на клоке). Работает на 2-х слойке.

Old Nick Много времени прошло и многое подзабылось. Сейчас я уже давно не занимаюсь этим проектом, но кое-что ответить могу. >> По моим наблюдениям, SRC успешно "отключается" установкой соответствующего volume control в >> пложение "максимум". Проверено в режиме file1.wav -> USB-AUDIO device -> SPDIF->SPDIF_input >> ->file2.wav. Совпадает побитно, не считая сдвига. Разумеется, не следует лить 48kHz.wav -> 44.1 >> USBaudio. Возможно так оно и есть, но не в моём случае. У меня дефолтовая частота дискретизации была 88.2 КГц, поэтому при работе в режимах 48,96 SRC работает всегда, но при 44.1 SRC хоть и работает тоже, но уже по другому алгоритму, по сути не SRC, просто фильтрация с децимацией, что даёт такое высокое качество при прослушивании типового аудио (CD,mp3 и т.д.) Это был мой компромисс. Более того, на честные 96 КГц у меня просто не хватало памяти на FIFO внутри чипа, поэтому и были выбраны 88.2. Позже я понял, что поступил правильно. >> 1.Под какими разливами мелкософта удается получить свыше 16бит и какими средствами и >> проблемами, помимо упомянутых? Этого я с уверенностью сказать не могу, нужно экспериментировать. Поскольку этот проект у меня заглох в силу того, что устройство оказалось никому не нужным (кроме, разумеется меня). В конференциях я видел посты о том, что в ВинХР реализована 24битность, но я уже это не проверял. >> 2.Хватает ли фифо на "слабых" машинах и активно используемой мышкой/клавиатурой на том же хабе? Я свою плату включал в USB порт всегда как единственную и про хабы ничего не скажу. Но ни при какой загрузке системы (тем более при активности мышки и прочее) никаких артефактов звука я не наблюдал. Например, при записи CD/DVD, копировании больших потоков данных, сильной активности сети, игрании в игрушку и прочее, звук абсолютно чистый и не прерывающийся. Этой платой я сам пользуюсь и её работой очень доволен. Единственное, я так и не смог запустить её под Линукс, там в ALSA нет SRC как такового и дальше разбираться я не стал. Объём буферов на плате у меня асолютно минимальный, то есть на 1 миллисекунду звука по два пинг-понг буфера, и всё. >> 3.Правильно ли я понял, что Вы использовали VCXO (vco с кварцем)? Какая надобность именно в управляемом генераторе? Да, у меня VCXO с PLL которой я хитро управляю. Это нужно только из за кривости встроенного драйвера usbaudio в MSwin. Ну не хотят они правильно реализовать адаптивный режим работы, поэтому пришлось пользоваться синхронным. Способ конечно, сомнительный, но пока я ещё не встречал ни одной материнки у которой бы нестабильно шли SOF пакеты (к ним я привязан). С наступающим!