coolshin
AirPlay 投屏音量控制：初始音量同步、音量曲线与跨平台实现
一个看似简单的满音量问题 先把接收端设备媒体音量调到最低，再从Apple设备发起AirPlay 投屏，投屏收发两端音量都变成满音量了！沿着这个现象继续测试，很快又遇到几组相关但不完全相同的问题： 发送端调节音量，已经拖到最低静音位置，接收端仍处于中等音量； 断开再投屏后，新的 RAOP 或 HLS 管线会把输出重新推回满音量； 修好初始同步后，Bilibi…
Categories
AirPlay
35 个包去了哪里：用日志和 Wireshark 追踪 AirPlay 音频丢包
深夜日志里的数字 35 一次 AirPlay 音频调试快结束时，日志里突然出现了这样一行： audio UDP receive queue overflow session=8 dropped_total=35 会话关闭时，它又留下了一份“结案统计”： audio_packets=35191 ... audio_kernel_drops=35 control…
让 iPhone 通过电脑代理访问网络：测试 YouTube 投屏
背景 调试 AirPlay 投屏时，经常会遇到这样的环境：电脑和 iPhone 已经连到同一个局域网，电脑上的 AirPlay 接收端也能被发现，但 iPhone 所在的网络不能直接访问 YouTube。这样连视频都打不开，自然没办法继续测试播放和投屏流程。 本文的大前提是：电脑可以正常访问外部网络，并且同时运行 AirPlay 接收端和 Clash Ver…
AirPlay 投屏设备发现稳定性：mDNS 缓存一致性问题定位与修复
背景 APlayReceiver 是 APlay 项目里的 Linux AirPlay/RAOP 接收端。Apple 设备发现 AirPlay 接收端依赖 Bonjour，也就是 mDNS + DNS-SD。 这次问题的现象是： 昨天 Apple 设备可以发现 APlayReceiver。 晚上设备自动休眠，没有关机，第二天 Apple 设备的投屏设备列表…
Wireshark 分析 AirPlay 投屏
背景 在调试 AirPlay 投屏接收端时，最容易遇到一个反直觉现象：接收端日志里明明已经收到了 SETUP、RECORD、SET_PARAMETER 等 RTSP 请求，但 Wireshark 里使用下面的``rtsp`显示过滤器却是空的： 这很容易让人怀疑： 是不是根本没有抓到 RTSP？ 是不是 AirPlay 使用的不是标准 RTSP？ 日志中为什…
AirPlay mDNS 双栈发现：A 和 AAAA 到底该怎么发
背景 在把 UxPlay 的 DNS-SD/Avahi 依赖替换为内置 mDNS responder 时，PR review 里出现了一个很典型的双栈问题： 使用内置 mdnsd 时，AirPlay 客户端会先建立一个 IPv4 TCP 连接，然后很快又建立一个 IPv6 TCP 连接，前一个 IPv4 连接被替换；使用 Avahi 时，只看到 IPv6…
APlay 为什么不把 mDNS 拆成独立进程
背景 在 UxPlay 的 PR #523 中，我们用内置的 mDNS responder 替换了 Avahi 依赖。PR 的 reviewer 提出了一个架构建议：是否应该把 mDNS 功能拆成独立进程，让用户自己选择用什么 mDNS 实现（Avahi、mDNSResponder 等）？ 这个建议本身很合理——桌面场景下确实可以这样分工。但当目标平台变成…
AirPlay mDNS Harness：模拟 AirPlay 设备的技术实现
在 APlay 项目中，mDNS 服务发现是 AirPlay/RAOP 设备被发现的基础。本文介绍的 AirPlay mDNS harness 借助一个轻量的验证框架，无需真实硬件，在单机上完成了 mDNS 协议实现的验证。本文从流程、代码到协议细节，完整解析这个"模拟设备"是如何工作的。 背景：为什么需要模拟设备 APlay 是一个支持 AirPlay/R…
AirPlay 投屏设备发现
背景：设备发现到底是什么？ AirPlay 设备发现不是"手机去扫局域网里所有 IP"，而是通过 mDNS/DNS-SD 完成的。 可以把它理解成局域网里的"小广播查询"： Apple 设备向 224.0.0.251:5353 或 IPv6 的 ff02::fb:5353 发 UDP 组播查询。 查询内容是"谁提供 _airplay._tcp.local…