一、响应时间¶
1.1 指标¶
端到端延迟 (End-to-End Latency): 从用户话说完最后一个音节的能量波谷（End of Speech，到系统开始响应（无论是TTS播报的第一个音节，还是车窗开始下降）的时间。参考
- 首字延迟 (Time to First Byte/TTFB): 用户说完后，TTS 第一个字发声的时间。它决定了交互的“节奏感”。优秀的 TTFB 能给用户带来“系统秒懂”的错觉。
Rule-of-thumb (经验法则): 交互延迟的“200/500/1000ms”黄金法则： * < 200ms: 用户感觉是“即时”响应，几乎无法察觉延迟。这是流式TTS的TTFB理想目标。 * < 500ms: 用户能感知到延迟，但感觉流畅，仍在自然对话的接受范围内。这是端到端延迟的及格线。 * > 1000ms (1s): 用户感到明显“卡顿”，产生“机器坏了”的疑虑，对话流被严重破坏。这是绝对要避免的红线。
车载交互的成败取决于响应速度。理想的目标是“首字延迟”（Time to First Token）在 500ms 以内，“首音延迟”（Time to First Sound）在 700ms 以内。
VAD的决策延迟直接影响用户感知的响应速度。一个优秀的VAD应该在语音开始后的50-100ms内给出判断。
VAD尾端点一般会进行静音检测，一般默认选择600ms。
一般情况下交付的指标以均值衡量。但也可以是：P99延迟，即第99百分位延迟，指的是在所有请求中，99%的请求响应时间都小于或等于该数值*。
1.2 计算¶
端侧链路：
因此，
- 把各类时间节点的脉冲达到SE输入音频中，从而人工校对人声尾端点和TTS首端点的时间差，即可获取播报响应时间（安静环境下，在电脑上写一个严格的vad检验逻辑也是可以的）。
- 这套方案的核心优势在于把音频上下行时间计算出来了，避免各组件之间扯皮。
SE延时：
- 硬延时：算法计算是按帧计算的，且不是每一帧都实时输出，例如输入的第1帧，在算法处理后，再第3帧输出，输出的第1帧、第2帧为空音频（或带一定底噪的音频）。这个概念类似线性相位系统的群延时。
- 软延时：CPU/APU 计算的延时，会随系统负载而波动。
- 实测方法：在安静环境下，播放衡频音频，对比输入输出文件，即可获取SE延时。
MVW延时：
- 由于唤醒需要的算力一般较低，无需单独过VAD，可直接计算算法的延时；
- 有些品牌允许倒数第二个字说完就唤醒，这种就可以显著主观感受上的响应时间；而一些品牌则把这些作为相似词明确要求不可唤醒的。
- 有些时候需要计算后处理时间，如车外唤醒防御、车内音区判决、声纹识别等。
- 多唤醒词场景时，注意因为算法阈值和策略的影响，响应时间会有差异。
本地SR延时：
- 这里的SR是广义上的SR模块，内部包含VAD、ASR（狭义）、NLP处理的时间，后两者可以直接通过日志直接获取。
- VAD延时：日志形式一般是这样的
timeA vadStart,即墙钟时间timeA对应帧时间0， 再有日志timeB vad end frame x, 假设vad每帧10ms，则vad尾端点大致在x * 10， 那么可以计算出vad的延时为：\(timeB - (timeA + x * 10)\)，注意这个计算结果包含了VAD计算的尾端点和实际尾端点的误差。 - 为了避免高噪场景下，vad频繁误触，出现上AI方案的vad,一般会设置一个TAIL参数，指定静音500ms ~ 800ms 左右后再抛出结果。正常情况下VAD实际延时和这个TAIL参数不会有很大的误差。
- 结合打字机（前提是打字机够快）的语义，结合打字机和可见即可说的匹配等策略，来提升VAD的时间。
打字机首响：考虑到vad 前端点误差就几针，实际首字已经超过了前端点导致的前期爆发送音影响了。端到端的时间为：首字说完到首字打字机在屏幕上显示。因此可以拆分为「SE延时+识别打字机算法延时+上屏显示延时」。对于云端，多考虑网络链路延时 + 数据包封装延时（合理设计一般不会导致送音不及时）。
云端识别响应时间：
- 一般是本地VAD触发后才像云端送音频。
- 由于厂商业务中转导致延时变大不可控。例如以前是端到云A，现在是端→云B→云C。另外语义的信源检索（音乐、导航、餐饮、天气等）也会导致延时变大。
- 一般不能单纯的计算上行链路时间和下行链路时间，因为虽然服务器的时间是经过严格的授时守时了，但成品库中的车机经常出问题。因此可以按本地处理时间（VAD时间、系统业务时间、TTS时间）+ （服务器业务处理总耗时），剩下的就是上下行链路的时间了。
二、术语¶
2.1 时间¶
测绘术语：
- UTC: Coordinated Universal Time， 0 时区，带闰秒；民用世界标准。
- Local Time: 系统时区偏移之后的日历时间
- CST: China Standard Time
计算机术语：
- 墙钟时间 Wall‑clock time： 受NTP调节
- 单调时间 Monotonic time：只计流逝时长，没有日历意义，不受 NTP 跳变影响。未严谨定义是否受深睡眠影响。
由于不同平台属于不同，可以超时用POSIX时钟进行标准术语进行沟通。（让大模型回复时映射一下）
| 时钟ID | 含义 | 是否受suspend深睡眠 | 是否可回拨 |
|---|---|---|---|
CLOCK_REALTIME |
墙钟时间（Wall‑clock），现实日历时间，Unix历元 | 休眠继续走 | ✅可NTP修改、可回退 |
CLOCK_MONOTONIC |
单调时钟，系统启动开始计数；休眠暂停 | 休眠停止增长 | ❌不能回退，允许频率微调 |
CLOCK_MONOTONIC_RAW |
原始单调时钟，不受NTP频率微调 | 休眠停止增长 | ❌不可回退、无NTP校正 |
CLOCK_BOOTTIME |
开机时间，包含所有suspend休眠时间 | 休眠继续累加 | ❌不可回退，允许频率微调 |
CLOCK_REALTIME_ALARM |
和REALTIME一样，用于闹钟；需要权限 | 休眠继续走 | ✅可回退 |
CLOCK_BOOTTIME_ALARM |
BOOTTIME 闹钟；需要权限 | 休眠继续累加 | ❌不可回退 |
2.2 授时和守时¶
时间同步协议NTP - 原理&实践 - warm3snow - 博客园 注：NTP offset计算做了上行实现和下行时间相同的假设。
程序员视角下的车载时钟同步 - lambda 的文章 - 知乎
三、环节延时¶
以下数据大模型帮检索的：
| 环节 | 正常轻负载 | 车机高负载（大量日志、CPU 打满） |
|---|---|---|
| App→logd 打时间戳 | <1ms | 1-10ms（内核调度竞争） |
| logd → adbd（车机内部） | 1-5ms | 20-100ms |
| ADB USB 传输到电脑 | 1-10ms | 50-300ms |
| 电脑终端渲染输出 | <5ms | 10-50ms |
| 端到端（Log.d() → 电脑屏幕看见） | 5-20ms | 100ms ~ 数秒 |
车机很容易出现：日志已经在车机内部生成了，但是电脑要等几百 ms 才刷出来；但日志行里面打印的时间戳依然是事件真实发生时刻。
| 方案 | 硬件条件 | 同步偏移(典型) | RMS抖动 | 备注 |
|---|---|---|---|---|
| A | 真实物理RS232串口 + GNSS模块PPS，原生Linux（非虚拟机） | ±1 ~ 10 μs | 10‑50 μs | 实验室理想条件，笔记本几乎无原生RS232 |
| B | USB‑TTL(FTDI/CP2102/CH340) + PPS，原生Linux，latency_timer=1 | ±0.2 ~ 1 ms | 1‑3 ms | USB是瓶颈，调优后；模块PPS边沿<100ns，被USB调度降格 |
| C | USB‑TTL + PPS，Linux虚拟机(VMware/VirtualBox)，USB透传 | ±0.5 ~ 2 ms | 2‑4 ms | 虚拟化再叠加一层调度抖动，你的推荐方案 |
| D | USB‑TTL + PPS，Windows Meinberg NTP | ±1 ~ 5 ms | 3‑8 ms | Windows串口驱动+第三方PPS驱动，抖动更大 |
| E | 普通USB‑GPS Dongle，只有NMEA，无PPS，Linux/Windows | ±20 ~ 100 ms | 30‑120 ms | NMEA文本传输抖动，不适合做时序基准 |
| F | 互联网公共NTP（pool.ntp.org），普通PC/车机 | ±5 ~ 50 ms | 10‑100 ms | 网络抖动，受路由、防火墙影响；车机无网直接失效 |