Xpeccy

[SAM style]

Блин ну не должно быть так, чтобы длину буфера к длительности кадров постоянно подгонять. Если аудио является основны якорем, и событие вывода графики генерируется из звукового рендера, то вообще не важно какая длина буфера, важны временнЫе отметки, а их уже можно о и с 50фпс и с 60фпс и с 59 генерировать (samplerate делить на эти самые привязанные к кадрам чанки).

Звук оказался не при чём. Делал буфер на 10 буферов/сек, и на 100 буферов/сек - всё одно. Косвенно отследил забиваемость очереди Qt (printf на сигнал по кадру, printf на слот, который к нему привязан) - сколько сигналов выпущено, столько раз и слот срабатывает. Бывает, что идёт 2 сигнала подряд, но за этим следует 2 вызова слота подряд. Очередь не забивается. Возможно, 2 перерисовки подряд как-то дурно влияют на GL...

- - - Добавлено - - -

Решилось Точно не знаю, почему так, но... До этого для перерисовки окна я делал setUpdatesEnabled(true); repaint(); setUpdatesEnabled(false); - обновления окна разрешены только здесь, чтобы система не перерисовывала его когда ей захочется.
С GL были огромные подозрения, что активный QPainter вызывает рекурсию. Поэтому я сделал прямой вызов paintEvent(nullptr) вместо предыдущей связки. Окно перерисовывается, но все другие обновления окна теперь запрещены всегда. И шо бы вы таки думали? Его теперь не колбасит - GameBoy стабильно держит свои 60фпс, NES в NTSC тоже...
Чудесато...
Чудесато то, что теперь оно накапливает задержку, но медлено...
Чудесато... без двойной буферизации не накапливает, но индикаторы иногда подмигивают