Есть такая задачка:
Требуется написать драйвер для USB устройства, которое будет преобразовывать некий аналоговый сигнал(!стерео) в цифровой, гнать его в комп(со скоростью ~3 мбит/сек)
Комп будет его обрабатывать по определенному алгоритму, отправлять обратно на этот девайс(со скоростью ~3 мбит/сек), который его преобразует обратно в аналог и подаст на выход.
То есть схема такая:

аналоговый сигнал -> Девайс -> цифра (->?как) комп (->?как) девайс -> аналог -> выход

суть вопроса: как мне лучше передать цифровой правый и левый каналы с девайса на комп и обратно?

есть два варианта:

1. чередовать биты - правый - левый и т.д.
2. чередовать пакеты по n бит правого потом столько же левого

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

Какой алгоритм эффективней?
что можно почитать по этому вопросу?

Вообще говоря, есть у Cignal'а такой себе аппнот, в котором они описывают USB радиоприемник. На чип самого приемника документацию пока получить не удалось, но для ваших целей это и не требуется. В аппноте описан цигналовский МК, ацепирующий данные от аналогового FM приемника и отправляющего их на комп по USB для проигрывания. По идее, начать можно с этой стороны. 6 мбит для USB это даже не вопрос, так что с этой стороны все должно быть нормально. Точность АЦП/ЦАП преобразований может быть проблемой.

очевидно что надо сходить на usb.org и почитать соответствующие доки на этот класс USB-устройств (гsb audio device) - а там может и стандартный виндовый драйвер заюзать. (я так понимаю реализация usb-function тоже отдана на откуп вам)


to v_mirgorodsky
если вы про Si4700/Si4701 то они выложили-таки полные доки (убрали требование NDA)

При чем тут драйвер? И зачем его вообще писать? Готовых же полно :-)

Т.е. нужно определиться с аппаратной частью. Это и есть главная печка, от которой следует плясать. Имеем задачу: преобразовать аналог с помощью АЦП, передать данные в комп, там обработать и получить обработанные данные обратно для выдачи их на ЦАП. Если речь идет о 3 Мбит/сек, т.е. примерно о 400 Кбайт/сек, то исходя из этих требований следует выбрать микросхему. IMHO, уложиться в USB 1.1 будет трудновато, да и под завязку (что почти всегда не хорошо). Поэтому представляется, что оптимальным выбором стала бы микросхема USB 2.0 (и, конечно, фирмы Сайпресс ;-)

Далее. Как передавать два канала. Трудно сказать... Но на первый взгляд представляется, что наиболее просто и естественно было бы передавать значения отсчетов обеих каналов параллельно, т.е. левый-правый, левый-правый и т.д.

Значит, однозначно USB 2.0.

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

По вопросу USB или по написанию драйверов? И то, и то - тяжелая задача... Из личного опыта могу сказать, что для решения вашей задачи ни того, ни другого изучать не требуется :-) Вам нужно передать данные туда и обратно. На сравнительно невысокой скорости. Это легко решается без всякого трудоемкого изучения литературы. IMHO, после выбора элементной базы USB следует просто изучить материалы изготовителя, аппноты, pdf'ы всякие... Думаю, этого будет вполне достаточно.

Ну а если имеется желание/потребность в изучении написания драйверов под USB - тут я пас...

Задам один вопрос - какая максимально допустимая задержка между входным потоком и выходным?

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

Не понял, при чем тут снова драйвер? Драйвер есть, он уже давно отлажен и превосходно работает во всех режимах (имею ввиду Сайпресс, с которым уже давно работаю). А выделить в прикладной программе нужное количество буферов - какие проблемы?

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

Я ведь не просто так задал вопрос про допустимую задержку между входным и выходным потоком.
И Alex11 совершенно прав. Windows не realtime система. Помещение кода обработки данных в драйвер, причем в dispatch level, еще может помочь в ситуации малой задержки.

Если задержка не важна, то можно обрабатывать и в user mode, в том числе и с помощью драйвера Cypress, используя bulk и не обязательно в High speed. Full speed справится с суммарным потоком 6мбит/сек.

А, вот о чем речь... Полностью согласен. Да, автору исходного вопроса следовало бы осветить этот момент.

К сожалению, насчет написания драйвера для такого устройства я ничего посоветовать не могу... Для меня драйвера - темный лес... :-)