Дублированный раздел ронял обновление трассировкой tomllib. Теперь
ConfigError объясняет по-русски, что раздел объявлен дважды и какие
разделы должны встречаться ровно один раз.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Токен и расшифровки разговоров ходили по сети открытым текстом. Теперь в
пакете лежит Caddy: он держит сертификаты Let's Encrypt и продлевает их сам,
а сервис уходит на localhost.
Отдельно решён вопрос подмены адреса: за прокси все запросы приходят с
localhost, и список разрешённых адресов пускал бы кого угодно. Заголовку
с настоящим адресом сервис верит только от доверенного прокси - на это
восемь тестов.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ключевая находка по записям с микрофоном на столе: без выравнивания тихий
дальний участник сливается с громким и разделение разваливается. Замер на
трёх разговорах: доля второго участника выросла с 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>
Полный трейс показал настоящую причину сбоя: падало не распознавание,
а метрика separation_quality из 0.5.0 - она скармливала модели отпечатков
реплики целиком, и на 190-секундной та не выдержала. Теперь берётся кусок
из середины реплики, а сбой оценки лишь обнуляет её, не трогая расшифровку.
Добавлен /v1/logs: последние записи журнала с фильтром по уровню, чтобы
разбирать сбои без копирования консоли вручную.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
На Windows процессы поднимаются через spawn и заново импортируют app.main.
Хранилище задач создавалось на уровне модуля, поэтому каждый новый процесс
при старте помечал чужие выполняющиеся задачи как сорванные - все три
записи падали с "сервис был перезапущен во время обработки".
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>
Масштабирование ONNX зависит от процессора: замеры на Apple M4 не
переносятся на Ryzen, а подбирать конфигурацию перезапусками мучительно.
Теперь /v1/benchmark гоняет минуту записи на 1, 2, 4, 8 и 16 потоках
и говорит, что поставить в config.toml.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Прогрет был только нулевой воркер, остальные получали пустой конвейер и
роняли задачу с "модели не загружены". В комментарии было написано, что
они греются сами, но кода для этого не было.
Заодно отключены ANSI-цвета uvicorn на Windows: консоль их не разбирает
и печатала управляющие последовательности как мусор.
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>
Штатные /docs и /openapi.json не требуют токена, поэтому раньше были
выключены совсем. Теперь это свои маршруты, закрытые тем же списком
адресов, что и остальной сервис: со своей машины открываются, с чужой
отдают 403. У методов появились описания, в схеме объявлен Bearer -
работает кнопка Authorize.
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>
Отказ по списку доступа отлаживался вслепую: сервис не сообщал, каким видит
адрес обратившегося. Теперь /health отдаёт your_ip, your_ip_allowed и версию,
не раскрывая при этом сам список.
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>
