Projekt-Setup: Live E-AC3 zu AC3 5.1 Konverter (Toslink In/Out via Radxa Rock Pi S)

Ausgangssituation & Problem:
In meiner Audiokette wird ein E-AC3 (Dolby Digital Plus / Atmos)-Stream unkonventionell, aber erfolgreich über ein optisches Toslink-Kabel von einem HDMI-Extractor (FeinTech AX210) übertragen. Meine nachfolgenden Geräte (ein Purelink-Konverter und ein Starkey StarLink TV Streamer für meine Hörgeräte) benötigen jedoch zwingend ein klassisches, abwärtskompatibles AC3 5.1 (Dolby Digital) Signal über Toslink. Insbesondere für die Hörgeräte ist es essenziell, dass das Signal ein echtes Mehrkanal-Signal bleibt, damit der Center-Kanal (die Dialoge) nicht verloren geht.
Fertige Hardware-Boxen auf dem Markt beherrschen diese spezifische Live-Transkodierung (E-AC3-zu-AC3-Konvertierung rein über Toslink) aufgrund von Industriestandards und Dolby-Lizenzgebühren nicht.
Das Ziel:
Ein ultrakompakter, autarker Hardware-Audio-Prozessor auf Linux-/FFmpeg-Basis, der das E-AC3-Signal live vom optischen Eingang abgreift, verzögerungsfrei in ein echtes AC3 5.1 Mehrkanal-Signal enkodiert und über einen optischen Ausgang wieder ausgibt. Kommen bereits fertiges AC3 oder Stereo (PCM) rein, sollen diese verlustfrei per Stream-Copy (Passthrough) durchgereicht werden. Die Latenzsteuerung wird dabei komplett an den nachfolgenden Denon-Receiver (via Quick-Select-Tasten) übergeben.
Geplante Hardware & Gehäuse-Integration:
Recheneinheit: Radxa Rock Pi S (RS308-D4W Version mit integriertem Quad-Core RK3308, 512 MB RAM, WLAN und U.FL-Antennenanschluss).
Gehäuse & Strom: Das Board wird unsichtbar in das Gehäuse eines bereits vorhandenen, aktiven 1x4 Toslink-Splitters implantiert. Die 5V-Stromversorgung wird direkt von der DC-Buchse des Splitters auf die GPIO-Pins des Rock Pi S gelötet.
Signalweg (Lötarbeit): Die Leiterbahn im Splitter wird aufgetrennt. Das elektrische Signal des optischen Empfängers (Vout) geht direkt in den SPDIF_RX-Pin des Rock Pi S. Das verarbeitete Signal geht vom SPDIF_TX-Pin des Rock Pi S zurück an den Verteilungs-Schaltkreis der optischen Ausgänge des Splitters.
Verwaltung: Über das integrierte WLAN wird im Live-Betrieb drahtlos per SSH auf das schlanke Linux-System zugegriffen.
Verkabelungs- und Pin-Plan (Header 1 & 2):
Strom (+5V): Header 1 – Pin #2 (VCC_5V)
Masse (GND): Header 1 – Pin #6 (GND)
Audio-Eingang (Vout): Header 2 – Pin #13 (SPDIF_RX / GPIO0_C2)
Audio-Ausgang (An Sende-Buchsen): Header 1 – Pin #15 (SPDIF_TX / GPIO0_C1)
Geplante Software-Logik (Automatisches Umschalt-Skript):
Ein Bash-Skript läuft als systemd-Hintergrunddienst, analysiert alle 12 Sekunden das Eingangsformat via ffprobe und schaltet die FFmpeg-Pipeline automatisch um.

Konkrete Fragen für diesen Thread:
Kann der integrierte S/PDIF-Controller des RK3308-Chips auf dem Radxa Rock Pi S mit dem offiziellen Linux-Image unkonventionelle E-AC3-Pakete über die GPIO-Eingangspins nativ im ALSA-Buffer abgreifen und verarbeiten?
Welche spezifischen Device Tree Overlays müssen in der /boot/uEnv.txt genau aktiviert werden, damit SPDIF_RX an Pin 13 und SPDIF_TX an Pin 15 unter Debian/Ubuntu stabil als ALSA-Geräte (hw:0,0 und hw:0,1) bereitstehen?