跑在 NAS / Home Server 上的本地音频投放服务
不挑协议，
投了就播。
手机和电脑继续使用 DLNA、AirPlay 与妙播；AI Agent 通过 MCP 播放 URL、本地文件或实时 PCM。声音统一送到标准 DLNA 音响。
核心链路仅在局域网
每台音响独立入口
amd64 · arm64
PUBLIC GHCR IMAGE · 公开镜像ghcr.io/djangoailab/castfabric:latest
amd64 · arm64 ↗
CURRENT SUPPORT · 当前支持从什么投，投到什么，一屏看清
均已实现
1 · 发送设备 / 接收协议现在可用
每台音响独立CastFabricRECEIVER SUITE
2 · 输出协议 / 设备现在可用
核心输出 · 本地NO ACCOUNT
DLNA MediaRenderer兼容的智能音箱、网络播放器、功放
AVTransport · RenderingControl可选兼容 · 云端需小米账号
Xiaomi MiNA没有原生 DLNA 的旧小米音箱；默认关闭
LEGACY MIAIR COMPATIBILITY手机沿用系统入口；AI 直接调用音响能力。
驱动实现 AVTransport 与 RenderingControl 的设备。
旧 MiAir 兼容路径；默认关闭并需要小米账号。
为后续输出适配器留出接口，不把规划写成支持。
PRODUCT PROOF · 真实产品
当前走哪条声路，
一眼就能确认。
控制台只展示能被系统确认的信息：发送设备、接收协议、输出音响、会话状态与失败原因；不猜来源 App，也不推测曲目。
最多展开三条活跃路径，其余聚合，不让音响数量破坏首页。
启停只影响当前音响的 Receiver Suite，不存在全局默认输出。
实体音响没有拉取 HTTP 音频时，不把控制命令成功冒充播放成功。
HOW IT WORKS · 三个实际步骤
发现音响，发布入口，
确认实体设备拉到声音。
发现局域网音响
扫描标准 UPnP/DLNA MediaRenderer，不要求先登录小米或其他厂商账号。
SSDP → device description → services发布独立接收入口
每台已启用音响获得自己的 DLNA、AirPlay 和妙播名称，多个房间可以同时存在。
Receiver Suite × output speaker把声音送到实体输出
CastFabric 不止发送控制命令，还确认实体 DMR 真正打开并拉取音频流。
SOAP Play → HTTP GET → verified outputRUN FROM GHCR · LINUX HOME SERVER
一条命令启动
CastFabric。
镜像公开托管在 GitHub Container Registry，提供 amd64 与 arm64。使用 host network，让 SSDP 和 mDNS 正常访问局域网；配置保存在宿主机目录。
查看完整部署与网络说明 ↗HOME-SERVER / CASTFABRIC
# pull and start from public GHCR $ docker run -d \ --name castfabric \ --restart unless-stopped \ --network host \ -v "$PWD/castfabric-conf:/app/conf" \ ghcr.io/djangoailab/castfabric:latest # open the console → http://HOME_SERVER_IP:8300
两条声路，两种延迟
查看测试证据 ↗
原生 DLNA 直投在当前测试音箱通常低于 1 秒；AirPlay 与妙播经过实时 PCM / DLNA 桥接约有 4 秒延迟，不适合需要音画同步的视频。不同音箱的缓冲策略不同，实际结果以设备为准。