[JGgp6E].
Это значит, что процессор не шлет сырые аудио-данные (PCM) [0vIv-2]. Вместо этого DMA гонит из памяти уже готовые 32-битные субкадры (Subframes) [0vIv-2], где внутри одного слова упакованы:
• Аудио-сэмпл (сдвинутый в 24-битный контейнер) [0vIv-2].
• Программные маркеры синхронизации/преамбул (B, M, W) [0vIv-2].
• Служебные биты подканала: V (Validity), U (User), P (Parity) и C (Channel Status) [0vIv-2].
По умолчанию подсистема ALSA оставляет блок Channel Status (C) пустым (заполненным нулями) [0vIv-2]. На языке протокола IEC60958 это означает, что передается «Non-Audio / Data stream» (поток данных, а не звук) [0vIv-2].
Что ожидает получить LT9611 на входе SPDIF_IN:
По умолчанию в режиме SPDIF (0x8406 = 0x0C) мост Lontium ожидает классический, чистый BMC-модулированный SPDIF-сигнал [0vIv-2]. Аппаратный декодер LT9611 пытается сам вычленить преамбулы и биты VUC&P из фронтов сигнала [0vIv-2].
Как эти форматы сталкиваются:
1. Конфликт упаковки (Почему булькало): LT9611 пытается наложить логику стандартного 24-битного PCM на входящие расширенные 32-битные субкадры [0vIv-2]. Встроенный FIFO-буфер LT9611 мгновенно переполняется служебными битами [0vIv-2]. Мост теряет фазу, что бьет обратно по линии и вызывает прерывания PREAMBLE_MISMATCH на i.MX95 [0vIv-2]. Драйвер процессора уходит в защитный перезапуск reset_rx_work, что приводило к прерывистому «бульканью» [0vIv-2].
2. Защита HDMI (Почему тишина): Когда вы стабилизировали частоту (например, выставив 0xD4), поток шел ровно [0vIv-2]. Но LT9611 считывал из субкадров процессора пустой Channel Status (Non-Audio/Data) и транслировал его в HDMI поток [0vIv-2]. Умные ТВ/мониторы, видя в HDMI-потоке маркер «Данные», мгновенно включают Mute (аппаратную заглушку звука), защищая динамики [0vIv-2].
