Минимально допустимый буфер , Как уменьшить задержку при программной обработке звука в "реальном времени"

Господа!

Пишу софтину обработки звука "реалтайм" (под реалтаймом понимается некая фиксированная задержка вход/выход).
Со звуком работаю через стандартный MMSystem, использую двойную буферизацию.
Интересует, как оптимизировать под минимальный размер буфера.

Пока результаты такие: буфер 50мс (плюс квота 10 мс на программную обработку буфера) - воспроизводится нормально. Ставлю буфер 25мс - щелчки.
Реально ли еще уменьшить буфер (то есть работать без щелчков с буфером меньшим, чем 50мс)?
Понимаю, что винда для реалтайма не предназначена, но всё же?

Краткое описание алгоритма.
1) На входе поставлено в очередь 2 буфера на запись. Один буфер записался, перепихиваем его, родимого, на обработку и сразу ставим обратно в очередь на запись. В этот момент идет запись в другой буфер. Готовность буфера определяем поллингом через мультимедийный таймер с интервалом в 1мс.
2) Делаем программную обработку принятого буфера.
3) В первый раз отсчитываем задержку в 10мс на обработку буфера, чтобы задать интервал между принятием входного буфера и постановкой его на выход.
4) Обработанный буфер пихаем на выход. Первый раз это делается через "нормировочную" задержку 10мс (п.2), далее - по появлению свободного буфера на вывод (там тоже крутятся 2 буфера).

Что еще можно сделать?
Поможет ли например переход на Директ Саунд? Мне кажется, что нет: пробовал вход выводить в файл (чтобы гарантированно отсечь щелчки вывода) - картина та же: 50мс - всё хорошо, 25мс - щелчки.
Поможет ли переход от программного поллинга на callback function? Попробую, но думаеццо, что щелчки здесь вызваны в первую очередь писюковыми прерываниями большего приоритета, и всё остальное только пляски с бубном...

Впрочем, кто писал подобные задачи, буду рад, если поделитесь опытом.

ymv
44100*2*0.05=4410
Что примерно равно одной странице.
4096. Возможно ваша аппаратура не может воспроизводить или записывать куски меньшего объема.
Хотя у меня где-то на 1500 байтах заикания начинались, что примерно равно одному такту. Но я тогда не включал реалтайм в виндоусе.

Цитата Pavia @ 14.04.14, 16:10

ymv
44100*2*0.05=4410
Что примерно равно одной странице.
4096. Возможно ваша аппаратура не может воспроизводить или записывать куски меньшего объема.
Хотя у меня где-то на 1500 байтах заикания начинались, что примерно равно одному такту. Но я тогда не включал реалтайм в виндоусе.

> 44100*2*0.05=4410
Без *2, буфер равен 2210.
Задержка определяется одним буфером. Второй буфер просто на подхвате.
Кстати, какая страница имеется в виду? В DMA я не силен.

Может, причина щелканий в том, что прерывание от звуковухи "забивает" более приоритетное прерывание? Готов звуковой блок, только драйвер звуковухи хочет установить флаг готовности, как тут же его, родимого, прерывает более приоритетное прерывание. А пока оно работает, уж тут готов и следующий звуковой блок. Впрочем, это только гипотеза. Кстати, прерывание от таймера писюкового генерится раз в 55мс...

В принципе, меня пока и такая задержка устроит, еще бы подвести теорию...

Кстати, а по поводу размера буфера - это мысль.
Попробовал увеличить SampleRate - щелчки прекратились.
Т.е.:
44100 буфер 50мс - без щелчков
44100 буфер 25мс - щелчки
96000 буфер 50мс - без щелчков
96000 буфер 25мс - без щелчков

Добавлено 15.04.14, 07:30
А кстати!!!
> Но я тогда не включал реалтайм в виндоусе.
Э-э-э-... А не будет ли столь любезен глубокоуважемый джинн подсказать, где в винде есть галочка включения реалтайма? :-)))))))))

>> 44100*2*0.05=4410
>Без *2, буфер равен 2210.

Вру, размер буфера 44100Hz*2bytes*2channels*0.05=8820
Или со щелчками 44100Hz*2bytes*2channels*0.025=4410

Судя по постам смелых экспериментаторов, достигнутый результат можно считать очень и очень хорошим:

Цитата http://technosaratov.ru/post/view/94

Так, например, не особенно утешительные заявления Microsoft о том что DirectSound обеспечивает задержки в 20мс не являются истиной. На практике достигаются лишь задержки в 50-80 мс.

Вумные люди для близкого к реалтайму звука советуют ASIO.

Добавлено 10.05.14, 20:17
Даже читаем доки по ДиректСаунд:

Цитата

Задержки звука

Подсистема MME из-за переключений между 32- и 16-разрядными режимами и неоптимальной с точки зрения адаптера структуры буферов часто дает существенную задержку (latency) между подачей звукового блока драйверу и появлением звука на выходе, равно как и в обратном направлении (при записи). DirectSound, за счет более оптимального управления адаптером, вносит задержки на уровне около 20 мс. Однако при эмуляции, когда работа идет через подсистему MME, задержки могут возрасти до 100-150 мс.

Добавлено 10.05.14, 20:41
А вообще, как в любом другом прожекте, я бы рекомендовал сосредоточиться для начала на собственных уникальных разработках. Я не думаю, что вывод звука является достойной самоцелью проекта - для этого есть вагон и малая тележка библиотек - BASS, FMod, и т.д. все они бесплатны для некоммерческого применения.

Почему? Потому что библиотеки эти писали не самые глупые люди, они используются в вагоне малой тележке проектов, в т.ч. коммерческих и высокобюджетных. Предоставляют одинаковые интерфейсы для различных платформ, т.е. для миграции потребуются минимальные изменения кода - а не танцы с бубнами, выжимают из железа по максимуму - так что, вероятнее всего, если дают работать с буфером определённого размера, то 99% что меньше на данной программно/аппаратной конфигурации и низзя, а самое главное, постоянно апгрейдятся, так что не нужно маяться геморроем по поводу выхода новых версий Винды.

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

Опыт показывает: когда разработчик застопаривается на вопросах вывода звука, и объясняет себе и другим что "дело дальше нейдёт потому что никак не выводится звук, а вот де только выведется так сразу всех порвём...", чаще всего остальная часть проекта не стоит выеденного яйца.

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

решение

Romzecs, пальцем в небо. Человек использует

Цитата ymv @ 14.04.14, 05:31

MMSystem

M

нарушение п.2 правил раздела.

Сообщение отредактировано: barazuk - 26.06.14, 17:01

> Рекомендую сделать сначала с использованием высокоуровневой библиотеки, а там будет видно:

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

> Опыт показывает: когда разработчик застопаривается на вопросах вывода звука, и объясняет себе и другим что "дело дальше нейдёт потому что
> никак не выводится звук, а вот де только выведется так сразу всех порвём...", чаще всего остальная часть проекта не стоит выеденного яйца.

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

> ... так что не нужно маяться геморроем по поводу выхода новых версий Винды.

Ну уж ничего стабильней и "системней" MMSystem не придумать.
За советы спасибо, я просто давно сюды не заходил, потому и молчал. Прога сейчас в состоянии альфа-версии, наверное если и буду прикручивать DirectSound и/или ASIO, то в последующих версиях. Правда, на других виндах завержки пока не тестил.