Ключевая находка по записям с микрофоном на столе: без выравнивания тихий
дальний участник сливается с громким и разделение разваливается. Замер на
трёх разговорах: доля второго участника выросла с 1.8 до 24.3 процента,
переключений между репликами - с 21 до 71 процента.
Работает только выравнивание: шумоподавление, полосовой фильтр и компандер
не дали ничего. Параметры подобраны замером, f=400:g=3 давал 8.6 процента
вместо 43.2. На распознавание не влияет - расшифровки фрагментов совпали
дословно.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Опрос статуса заставлял принимающую сторону дёргать сервис каждые
несколько секунд. Теперь при завершении задачи результат уходит POST-ом
на заданный адрес, с подписью HMAC-SHA256 в заголовке и тремя попытками
при неудаче. Адрес задаётся в настройках или параметром запроса.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Замер подтвердил догадку: sherpa-onnx и onnxruntime держат GIL. Две задачи
в двух потоках идут ровно столько же, сколько подряд (1.04x у диаризации,
1.17x у распознавания) - отсюда и незагруженный процессор при работе.
В двух процессах те же задачи дают 1.59x даже с загрузкой моделей в каждом.
Пул процессов включается при workers > 1. Функции воркера вынесены в модуль,
не тянущий app.main: на Windows дочерний процесс поднимается через spawn и
иначе стартовал бы ещё один веб-сервер. Если процессы не запустятся, сервис
откатывается на однопроцессный режим.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Бенчмарк на Ryzen 9 9950X показал обратное тому, что было на Apple M4:
там всё растёт до 16 потоков (распознавание x14.7 -> x61.3), здесь после
четырёх начинается спад. Причина в неоднородных ядрах M4.
Дефолт стал умеренным (половина ядер, но не больше 8), а точное значение
подбирается через /v1/benchmark. Воркер по умолчанию один: параллельная
обработка выигрыша не дала, процессор и так загружен целиком.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Замеры: распознавание даёт x52 на 4 потоках против x13 на 16, разделение
говорящих x33 против x8. Дальше четырёх потоков синхронизация съедает весь
выигрыш, поэтому ядра занимаются несколькими задачами сразу.
По умолчанию 4 потока на задачу и до 4 задач параллельно. Захват задачи
из очереди стал атомарным - без этого два воркера брали одну и ту же.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Правки в app/config.py не действуют и теряются при обновлении: это код,
а настройки читаются из config.toml. Теперь при старте печатается путь
к нему и что фактически применилось - задан ли токен и сколько адресов
разрешено. В самом модуле - предупреждение вверху файла.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Локальный FastAPI-сервис поверх GigaAM v3 и sherpa-onnx: приём аудио,
очередь задач, разделение по говорящим, постобработка терминов.
Доставка на Windows - ZIP со встроенным Python, без установки чего-либо.
Обновление кода при запуске тянется из релизов Gitea: меняется только
папка app, десятки килобайт вместо всего пакета.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
