3 Commits

Include renames

Author	SHA1	Message	Date
ew8bakandClaude Opus 5	79132f133c	fix(tci): рекордер линейного выхода — память под потолком, файл только в своём каталоге ... Два дефекта уровня P1 в LINE_OUT_RECORDER_*. Авторизации в протоколе нет (§3.1), bind наружу разрешён — значит «сколько стоит одна строка из сети» это вопрос живучести процесса, а не аккуратности. 1. Неограниченное выделение памяти. CmdRecorder проверял только ValidRx (номер в потолке), а конструктор выделял буфер целиком: 300 с × 48 кГц × 2 канала × int16 = 57.6 МБ на команду, приёмников 1+MAX_SLICES=7, то есть 403 МБ семью строками. У мёртвого приёмника Feed не зовут — значит срок записи никто не проверял; уход клиента рекордеры не трогал вовсе; DropDeadRxStreams бежит только на rfDevice/rfConnected и смене карты слайсов, в покое не срабатывает. Память жила до остановки сервера. Лечение тремя замками: - память набирается кусками по секунде, START не стоит ни байта; куски не перевыделяются (никакого realloc в DSP-потоке) и склеиваются один раз в Take — уже после того, как рекордер вынут из таблицы; - общий бюджет TCI_RECORD_MAX_BYTES (128 МБ) на все рекордеры сразу, спрашивается на каждый кусок; отказ не рушит запись, набранное остаётся сохраняемым; - освобождение по трём событиям: START требует живого приёмника (RxActive, ответ receiver is not running), тик сервера подметает истёкшие окна по часам (SweepRecorders — окно закрывается от START и без единого блока звука), уход клиента забирает его записи (DropClientRecorders; рекордер живёт на приёмнике, но платит за него тот, кто нажал START). 2. Перезапись произвольного файла. Путь из сети уходил в fmCreate почти как пришёл — вместе с '..' и абсолютными путями. Теперь TCIRecordPath берёт из строки ТОЛЬКО имя файла, каталог — настроенный tci.record_dir (пусто = <каталог конфигурации>/records). Каталог из просьбы отбрасывается молча: полный путь на сервере клиенту всё равно бесполезен, файл ложится не на его машину. Имя валидируется (пусто, '.', '..', управляющие, ':', длиннее 120, расширение не .wav → bad file name); после ExtractFileName выйти за каталог нечем. Файл создаётся эксклюзивно (TCICreateNewFile: O_EXCL|O_NOFOLLOW на Unix, CREATE_NEW на Windows) — ни перезаписи, ни симлинка, без окна между FileExists и созданием; клиенту заранее file exists. Попутно: MainForm.ApplyTCISettings собирал TTCISettings по полям с чистого листа — новое поле RecordDir обнулялось бы при каждом применении вкладки CAT. В uses TCIStreams Windows стоит первым намеренно: иначе его TCriticalSection перекрыл бы SyncObjs (та же грабля, что в DX-кластере). Стенд 189/189 (было 169): 11 проверок имени файла (/etc/passwd.wav, ../../.., D|\rec\a.wav), бюджет (START не выделяет, растёт кусками, потолок, отказ не рушит запись, срок истекает без Feed), существующий WAV не перезаписывается, START на мёртвом приёмнике и с чужим номером, и сквозная проверка в части E — клиент стартует запись, набирает память живым звуком через WDSP, рвёт TCP, бюджет возвращается к нулю. Без фиксов новые проверки краснеют. GUI (--ws=qt6) и демон зелёные. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 12:30:36 +03:00
ew8bakandClaude Opus 5	dc6f996e70	fix(tci): дефекты живого прогона — length аудио, маршруты тапов, MOX, рекордер, EOF сокета ... Восемь дефектов, найденных прогоном настоящего TCI-клиента (три приёмника: NFM, DIGU, FMRAW) и его отчётом. 1. UI доп. панорам не перерисовывался: rfSliceState рассылался, но ветки в MainForm.OnControllerState не было (частоту несёт отдельный rfSliceFreq). 2. Stream.length у аудио — сэмплы НА КАНАЛ (§4.3), у IQ — вещественные отсчёты (§3.4: комплексных = length/channels). Было ×каналы везде, у стерео получалось вдвое больше. Развилка в TCIFillHeader + разбор TX-аудио в HandleBinary. 3+4. Дыры в маршрутах аудио движка: demod-тап звался только для DMR/FMRAW (у DIGU не было RX_AUDIO), а пост-громкостный — только для нецифровых (у FMRAW не было LINEOUT). Плюс мьют слайса больше не убивает RX_AUDIO: движку сообщают SetAudioTapsActive. 5. Клиент, поставивший TRX, уходил — MOX оставался. FTrxOwner + StopTxOf; TCIMicRequested снимается и по окончании любой передачи. 6. Гонка снятия IQ-тапа: SetIQTap(nil) возвращался раньше, чем DSP-поток выходил из вызова. FIQTapLock (порядок FSliceLock → FIQTapLock). 7. Рекордер был кольцом «последние N секунд», а §4.3 говорит про МАКСИМАЛЬНОЕ время записи с удалением по истечении. Переделан в линейный буфер с окном по часам от START. 8. TCIServer.HandleClient считал recv = 0 таймаутом: ноль — это EOF, errno при нём не трогается и несёт EAGAIN от прошлого истёкшего TCI_POLL_MS. Обычный TCP-разрыв без close-кадра не освобождал слот до остановки сервера, и после нескольких аварийных отключений новые клиенты упирались в TCI_MAX_CLIENTS. Теперь R = 0 рвёт связь безусловно, errno спрашивается только при R < 0. Попутно: MainForm.RecreateDSPEngine (смена sample rate до START) терял внутренние колбэки контроллера — введён AttachEngineCallbacks. Стенд test/tci заведён в репозиторий (run.sh, 126/126 зелёных, включая сквозной прогон через живой WDSP), доп. проверки на оба пути отключения клиента. doc/TCI.md приведена в соответствие: правило про recv = 0 в §1.1, единицы Stream.length, линейный буфер рекордера. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 18:10:29 +03:00
ew8bakandClaude Opus 5	de0830fd19	feat(tci): этап 2 — бинарные потоки IQ/аудио, TX-аудио и запись линейного выхода ... Реализованы все четыре потока §3.4 и рекордер: • RX_AUDIO_STREAM — тап ДО громкости и мьюта (OnDemodAudioReady): скиммеру и цифре нужен звук приёмника, а не то, что осталось после ручки; • LINEOUT_STREAM — тап ПОСЛЕ (OnAudioReady), то есть что слышно; • IQ_STREAM — тап сырого IQ в движке, ОДИН вызов на накопленный блок; • TX_AUDIO_STREAM + TX_CHRONO — TRX:0,true,tci берёт модуляцию из потока клиента (флаг TCIMicRequested впереди web в SetMOX), маркеры времени идут из тика по часам, аудио клиента разворачивается в 48 кГц моно в тот же ринг, что и web-микрофон; • LINE_OUT_RECORDER_* — кольцо int16 на приёмник, WAV пишет отдельный поток. Тапы аудио в контроллере многоадресные (AddAudioTap): слушают, ничего не забирая, в отличие от OnAudioConsume, которым владеет web. Блоки нарезает и раскладывает по кольцам клиентов сам DSP-поток, в сокет пишет поток клиента — та же дисциплина, что у команд. Порядок локов везде FSliceLock → FStreamLock. У очереди команд и кольца блоков разная политика переполнения: команду терять нельзя, блок потока — можно (теряется самый старый). Пересчёт частоты многоступенчатый (TCIStreams). Одноступенчатый FIR на верхнем пресете Pluto (5760 кГц, коэффициент 120) упирался в потолок отводов и давал завал 1.3 дБ в полосе при подавлении зеркала 16 дБ — то есть поток IQ с мусором. Теперь коэффициент раскладывается на множители, спецификацию фильтра каждой ступени задаёт ИТОГОВАЯ полоса, а свёртка идёт со сложением симметричных пар: −83 дБ на любом коэффициенте, ≈10% ядра на 5.76 МГц. Согласование частот с железом: из пресетов Pluto 576 и 960 кГц на 384 не делятся, поэтому отдаём наибольшую ЗАКОННУЮ частоту, делящую источник нацело (576/960 → 192 кГц). Ответ на IQ_SAMPLERATE называет достижимое, а не просьбу клиента, и переобъявляется без запроса при смене rate и устройства. Приёмный буфер соединения 4 → 32 КБ: блок TX-аудио это 64 байта заголовка плюс data[16384], а кадр крупнее буфера не собирается никогда. Настройки TCI переехали из Advanced на вкладку CAT, справа от TCP CAT Server: это такой же канал внешнего управления трансивером. Стенд (scratchpad, tcitest.pas): 112 проверок, все зелёные — включая сквозной прогон через живой WDSP (синтетический IQ → блоки RX-аудио и IQ у настоящего WS-клиента, и обратно TX-аудио клиента → блоки TX-IQ). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:36:50 +03:00