Ну вот, а то сразу -- ракеты... Вроде не пятница еще

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

Galkov, ну зачем же так. Это единственное стандартное устройство в компе, которое воспринимает и выдает аналоговые сигналы. Единственно из за него и держу "идиотский ящик"

Андрей., а в чем проблема, в фул дуплексе звуковуха это позволяет.

ХЭМ, Андрей. имел ввиду, что винда - это не реалтаймовая ОС, и запросто может заняться чем угодно, но только не тем, что ты хочешь У звуковухи, в связи с этим, есть буфер, и его надо заполнить на несколько сот миллисекунд вперёд. И это никак не предрасполагает к мгновенному ответу, как минимум, ответ придёт не ранее, чем длина этого буфера.

Абсолютно.
Философский вывод: те строители систем, кто замыкает ОС на комп - больны на голову
Такие у меня были размышления, когда я проектировал пресловутый тот самый координатный стол (который к ракетам не имеет никакого отношения, а есть часть "координатки").
Есть требования к движению (предположим - по кругу), рожденные, естественно, на компе из неких графических файлов, есть электродвигатель постоянного тока (пусть питается неким ШИМ-ом), есть датчик положения координаты (ЛИР-350 - два цифровых сигнала + некие концевики)

И реализация здесь конкретно этого философского положения, такова: ни в коем случае НЕ должен комп формировать ШИМ, опираясь на знание траектории и сигналов от датчика положения.
Опять же отдельный девайс (не комп!) обслуживает эту ОС, получая от компа траекторию движения. С возможностью буферизации до 3-х секунд, как уже отмечал.
Были, правда, вопросы синхронизации всех координат...

tsdima, ну почему же несколько сот. Буфер можно коротким сделать, хоть из одного байта в режиме моно, 8 бит, а это при 44100 Гц будет 23 мкс.

ХЭМ, сам-то пробовал? Есть определённый сигнал, что определённая позиция в буфере была пройдена, т.е. данные до этой позиции были скопированы в физический буфер звуковухи. Так вот сигнал этот драйвер звуковухи в винде не будет посылать так часто, как ты хочешь, и физический буфер звуковухи заполняется довольно большими блоками. Вот нужно заполнить драйверу, скажем, 16Кб данных (половину физического буфера, хотя реально, вроде, меньшими порциями, типа по 2Кб, зависит от драйвера и частоты дискретизации) - он их и заполнит из твоего буфера, и отметит все позиции как пройденные, а то, что в результате это будут повторения твоего маленького буфера, так это ты сам виноват.

Извиняюсь,что отсутствовал в самый разгар дискуссии спасибо всем кто ответил.Мне тут умные люди уже обьяснили,что винды не являются ОС реального времени и т.д. и т.п. короче нужно делать на pic-контроллере.

[size=-2]------ Добавлено в 17:03

чел-это звучит гордо!

tsdima, на сильно коротких буферах не пробовал, но попробую в понедельник. Сейчас обрабатываю сообщения драйвера через CallbackFunction+PostMessage главному окну и вроде бы слышимых разрывов нет. Но вопрос канешна интересный, надо бы измерить. Хотя, пусть будет не 23 мкс, а скажем 1 мс - и то мясо.

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

pic-контроллер - отстой

Ню-ню, измерь, интересно-же знать, какой минимальной длины буфер передаётся звуковухе.