HarmonyOS 鸿蒙Next中关于音频服务中UltraFastFlag的问题

HarmonyOS 鸿蒙Next中关于音频服务中UltraFastFlag的问题 我注意到，从OS6.1开始，使用hidumper -s AudioPolicyService的时候，在快速音轨下出现了一个新的特性：

UltraFastFlag: 0

cke_18248.png

推测可能是给华为音悦家用的。

普通APP在ohaudio中设置usage为game且设置为低延迟后，只能走到普通的低延迟路径。考虑到部分类型游戏（如音乐节奏类游戏，也叫音游）对音频延迟要求比较高，使用开源社区音游Phira，结合打击音测量到使用USB音频输出的打击音延迟（也叫做Tap To Tone测试）大概在50ms左右

cke_20899.png

与此同时查看火焰图的缓冲区为5ms

cke_17612.png

同样是音游，iPad OS下测量得到的音频延迟（Tap To Tone）大概在30ms左右

cke_91372.png（因为游戏内音频实现不一样，iPad中使用的是Unity Criware中间件实现的低延迟音频，iPad的延迟会嫖一些，但是其他不使用Criware的游戏无此问题）

我推测UltraFastFlag应该是类似于高通的Ultra Low-Latency的类似物，所以想问一下华为官方，是否有计划给普通APP或者游戏使用UltraFast的权限？

同时我注意到

https://gitcode.com/openharmony/multimedia_audio_framework/blob/OpenHarmony-7.0-Beta1/services/audio_policy/server/service/service_main/src/audio_core_service_private.cpp

中的第99行

static const std::set<std::string> supportUltraFastBundleSet_ = {

};

似乎是采用了白名单机制。

因为iPad的音频延迟实在是太低了，最主要是他也开放给普通APP用，如果华为官方本身不希望开放UltraFastFlag音频的，我希望官方能开放给普通APP使用。


更多关于HarmonyOS 鸿蒙Next中关于音频服务中UltraFastFlag的问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html

3 回复

尊敬的开发者，您好：

当前UltraFastFlag低时延模式对设备芯片性能及应用场景有较高要求，使用条件较为严格。若配置不当，可能会出现卡顿等现象。因此，该特性目前仅作为Beta能力向内部系统应用开放，暂不开放给普通应用使用。

更多关于HarmonyOS 鸿蒙Next中关于音频服务中UltraFastFlag的问题的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


UltraFastFlag是HarmonyOS NEXT音频流的高性能标志，用于启用极低延迟音频通路。设置后系统优先保证响应速度，但会增加功耗并限制音频效果处理。该标志通常适用于对实时性要求极高的场景（如K歌耳返、游戏音效）。使用时需通过AudioStreamInfo的performanceMode字段配置，并确保权限和音频焦点正确设置。

UltraFastFlag 是系统为特定白名单应用提供的更激进的低延迟音频通道，当前 supportUltraFastBundleSet_ 为空，说明尚未对第三方开放。普通应用申请低延迟只能走上层通用路径，所以端到端延迟（USB 场景约 50ms）明显高于使用了专用中间件的竞品平台。这是系统调度与权限控制的结果，而非 API 限制。官方是否开放该能力给普通应用，目前没有公开计划，开发者只能继续使用现有的低延迟模式。

回到顶部