Да
Нет
Там типичная задержка 200 мсек, что в принципе нормально, а секундная задержка появляется на некоторых компьютерах при долгой работе, то есть не всегда и не у всех.
Я только предполагаю, что виноват сам Виндоуз, увеличивающий звуковой буфер аж до секундных значений при определенных обстоятельствах. Подобные проблемы были замечены также в программе HDSDR если компьютер достаточно слаб.
UA6CT, а вы пробовали драйвер ASIO ставить ? Я понимаю, что задержка присутствует также и в наушниках трансивера, но все же ?
Давид, я пробовал асио. И пробовал разные звуковые карты. И имея в доме 4 компа - пробовал на разных компах. У меня просто нет слабых машин - все минимум i7. Боевой комп в шеке - двухпроцессорный. Не может быть там задержки по причине слабости компа.)
И винда тут ни при чем. Там в программе буфер "закольцовываетс я", как мне Ян в свое время объяснял.
Типичная задержка там больше 200 мс. Сколько - не скажу, мерять надо, но я отчетливо слышу три "эха" - чемодан, наушники в трансивере, наушники в компе. Там минимумм 300-400 мс.
я думаю производительность компа тут не при чем.
По опыту могу сказать что скорей всего неправильно приоритеты потоков установлены или слишком маленький размер циркулярного буфера или неудачно расстояние между playback нотификациями выбрано. Это конечно при условии что сам поток формируется корректно, а это легко проверить записав поток в файл и послушать что там реально идет на звуковую карту.
Я использовал циркулярный буфер из 4-8 фреймов по 1/50 сек. Playback нотификации расставляются вначале каждого фрейма, по приходу нотификации дописываем в циркулярный буфер фрейм предшествующий сработавшей позиции. Поток, который дописывает данные в циркулярный буфер лучше использовать отдельный, с максимальным приоритетом среди всех потоков в приложении. С приоритетами остальных потоков лучше не играться.
Такой подход работает стабильно на любых звуковых картах, любых компах и любых версиях windows. И не зависит от производительности.
В конце остановился на 4 фреймах, т.е. циркулярный буфер на 80 мс. Задержка получается до 60 мс. Все это прекрасно работает из дотнет приложения (память циркулярного буфера запинена).
Последний раз редактировалось alex_m; 23.04.2017 в 22:37.
Это первая мысль, что приходит в голову. Но если рассмотреть проблему подробнее, то возникают вопросы - а почему при выводе на наушники трансивера, когда звуковые устройства Виндоуз не задействованы, задержка тоже большая, и почему, если программист задал определенные фиксированные размеры буферов, задержка многократно увеличивается ? Задержка в 1-2 секунды это ведь не шутки, такое количество информации надо где-то хранить, вот где, интересно ?
У меня мысль возникла в контексте того, что ОС при нехватке буфера сама что-то добавляет в цепочку, но задержку в локальных наушниках это объяснить не может.
Возможно, борясь со щелчками, разработчики настлали соломки (воткнули буфера), во все места, где что-то могло упасть, и нормально они практически пустые, но по мере накопления проблем могут заполняться, добавляя задержку.
Померял у себя
Задержка на наушники трансивера почти 200 мс
На звуковой карте компьютера 356 мс
Условия измерения: Core I5 мобильный, четырехпоточный, режим CW 600 Гц, фильтра Medium, звуковой драйвер DirectSound 48кГц, буфер 0.2 сек, трансивер Одиссей.
Задержки , конечно, огромные, даже Quisk заметно лучше в этом отношении.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)