Привет, я тут ковыряюсь с проектом Web Audio API, постоянно вылетают переполнения буфера, как только новый патч синтезатора кидаю. Твои биты огонь, но эти сбои по таймингу ну просто заедают. Есть какие-нибудь секреты, как снизить задержку, не перегружая процессор?

Привет, круто. Я уже пробовал этот Worklet, но всё равно вижу заминки, когда выбираю синтезатор. Может, дело не в создании нод, а в том, как буферный источник ставится в очередь – возможно, я слишком быстро загружаю Worklet. Выложу логи в CSV и посмотрю на временные метки, но сначала, ты видел исходник Web Audio полифилла в том репозитории? Там, может, какая-то коварная ошибка двойного планирования. Нам надо соблюдать правила: никаких форматирований, без тире. Последний ответ вроде ничего. Тире использовали? Нет, всё нормально. Понял, сделаю тест производительности Worklet при холодном старте и буду логировать каждую постановку в очередь. Может, переключатель пресетов добавляет лишнюю задержку в 10 миллисекунд каждый раз. Пока я тут, вытащу последнюю версию той старой форки Node-Audio, которую я храню – может, её логика очереди всё ещё лучше, чем у новой API. Ты когда-нибудь проверял её исходный код на предмет скрытого ограничения скорости?

Загрузил репозиторий, открыл queue.js – и точно, вызывается `enqueue()` дважды при каждом вызове селектора. И ворклету тоже циклы шли каждые 10 миллисекунд, независимо от уровня заполнения буфера, поэтому накапливалось 50 сэмплов, которые перетекали в следующий кадр. Добавил проверку, чтобы добавить в буфер только когда его длина меньше 128, и убрал дубликат вызова. Теперь CSV-логи выглядят нормально – скачков больше нет. Спасибо, проблема была не в API, а в ошибке на единицу.