В большинстве звуковых карт есть отклонение генератора от стандартных частот семплирования. Например вместо 44100 может быть 43095. На слух никто никогда не услышит, но за пару минут воспроизведения звук может отстать от какого-нибудь движущегося курсора, который рассчитывал на 44100 и опирается на системные часы. Это вступление (-;
Мне требовалось синхронизировать курсор аудио-редактора со звуком. Хотелось, чтобы юзер слышав «тынц» видел как курсор пробегает по тынцу прямо в этот момент. Интерфейс - Qt 4.8, язык C++.
Решение было такое: по таймеру QTimer (точность которого побоку) происходило обновление виджета 30 или 60 раз в секунду, на котором бежал курсор. Во время выполнения функции отрисовки, вычислялась текущая позиция курсора на основе samplerate и текущего времени, которое в этой функции бралось из каких-то там часов, уже не помню каких, наверное какой-нибудь boost.
Точный фактический samplerate звуковухи мерял путём измерения средней скорости (за время ~10 секунд), с которой звуковуха пожирает семплы.
Без такого замера на большинстве испытываемых звуковух курсор постепенно уезжал.
Спрашивал у одного мужика, разработчика чисто виндового звукового редактора, как он синхронизирует курсор со звуком - говорит, что спрашивает у винды текущую воспроизводимую позицию.
Как в linux принято спрашивать текущую воспроизводимую позицию, если там есть ALSA/JACK/PulseAudio и наверное другие средства загнать семплы в звуковуху? Есть ли для каждого средство узнать точный момент начала вопроизведения или даже текущий воспроизводимый семпл? А то бывает, что приложение семплы в звуковуху отправило, пошло дальше работать, а звука ещё какое-то время нет.
Интересует также вопрос производительности. Тут есть 2 момента
1) ходить в ядро глядеть на часы относительно дорого. Хотя я в этом плохо разбираюсь, но почему-то у меня сформировалось такое ощущение.
2) Нужно как-то понять, когда именно рисовать виджет. Просто фигачить перерисовку по таймеру, как я, - это криво, т.к. у меня может быть кривой таймер и у меня могут сбиваться кадры - т.е. я могу нарисовать очередной кадр уже после того, как кадр ушёл в монитор. Тут тема широкая, скажите хоть какую-нибудь речь. Покадровой синхронизации конечно не требуется, т.к. на 100-герцовом мониторе мне незачем фигачить 100fps, ибо при 30 оно уже плавно. Другое дело, что когда я под виндой попытался дать 30 fps, оно выглядело как 15fps, хотя те же 30fps на линуксе выглядят очень плавно. В кино по-моему 24 и никто не жалуется особо, новые видеокамеры умеют 60 - это добавляет плавности, да. Конечно 30 и 60fps на глаз заметны, но не так, как разница между 15 и 30.
При вертикальной синхронизации я буду нагружать проц тем больше, чем больше fps монитора, а мне этого не нужно - хочется просто разумного fps, типа 30, но стабильного. Тут уже требуется совет разрабов видеоплееров.
Спасибо.
