HarmonyOS 7 新特性2：音频编创——轻音台里的降噪、环绕与格式转换

1、引言

我的音频后期一直在 PC 上处理：录完一段口播，进 DAW 先降噪，再给环境音加一点环绕，EQ 拉一拉，导出。整套动作依赖插件宿主把一个个效果器串成链。把这条工作流往鸿蒙设备侧搬的时候，断点就出在“效果加工”这一步——端侧没有现成的插件宿主，自己移植第三方算法库要面对 SIMD intrinsics 和线程调度的全套成本。

鸿蒙给出的端侧答案是音频编创（OHAudioSuite）：一套纯 C/C++ 接口，引擎→管线→节点三级模型，12 种效果节点（降噪、均衡器、空间渲染、音源分离等），离线编辑与实时预览两种工作模式。这里先说明一下API对应的版本：OHAudioSuite 主体自 API 22 起提供（空间渲染、变声、变速自 API 23），它不算 7.0 的新特性；HarmonyOS 7.0 (API 26) 的真实增量在发布说明 Audio Kit 章节里——Beta2「新增基于 C/C++ 的音频格式转换能力」，以及 API 参考面的 HOA 空间音频节点、声道布局扩至 41 种、实时预览管线数量解禁等。所以本篇的结构是：底座能力做主线实测，7.0 增量（格式转换器）做加餐实测，两层分开写，不把旧能力包装成新特性。

这篇记录我在「轻音台」上把整条链路真机跑通的过程：降噪前后 RMS 与输出字节自洽、戴耳机可听的绕头环绕、播放中切 EQ 预置、转换器字节比与理论值逐位吻合；外加四个排查闭环，其中帧长单位那个坑，是官方示例公式与 OHAudio 接口文档口径不一致造成的，真机数据来彻底定位。

2、效果展示与项目结构

先交代载体。轻音台是一个「声音素材加工台」形态的应用：素材进 → 效果出 → 成品出库，产品动线正好和音频编创的两种管线模式同构。四个 Tab 里素材库是真实素材加 Mock 混合（内置 2 条真实素材可直接加工，6 条 Mock 素材置灰撑产品框架），成品库与我的暂未实现，加工台是全应用真实功能链路。当前版本界面是功能优先的演示级排版，产品级视觉在后续迭代做，本篇只保证行为与数据真实。

素材库首屏，两条真实素材（带噪人声 30.4s、棕噪声 8.0s）可直接进加工台：

加工台首屏。顶部是 14 种节点类型的能力探测结果（IsNodeTypeSupported 全类型跑一遍），本机全绿——包括依赖 NPU 的音源分离 204 和 26.0.0 新增的 HOA 节点 212，这个结果本身就是本篇数据之一：

降噪实测结果。输入 RMS -16.91 dBFS（48kHz/2ch 带噪人声），输出 -18.22 dBFS（16kHz/1ch，降噪节点官方输出格式），渲染 4479ms、输出 951KB：

空间渲染播放中（旋转模式，8 秒一周逆时针），戴耳机能听到声源绕头转：

播完自动释放后的帧耗时实测：RenderFrame 400 次、单次最大 2.31ms、超 20ms 预算 0 次。这行数字是修完帧长单位坑之后的口径，来历见 6.1：

均衡器播放中切预置：会话启动时应用 UI 当前选中的摇滚（hilog 记 preset=8 ret=0），播放中点中国风（preset=2 ret=0）即时生效，验证了「实时预览中不可新建节点、只可改参数」这条官方约束下的参数热更新路径：

格式转换器实测（26.0.0 新增）：44.1kHz→48kHz，字节比 1.0884 与理论值 48000/44100 逐位吻合，861KB→938KB、耗时 34ms：

工程结构增量如下，C++ 侧按职责分五个编译单元，ArkTS 侧加工台只表达业务意图：

entry/src/main/
├── cpp/
│   ├── CMakeLists.txt              // 链接 libohaudio.so + libohaudiosuite.so + librawfile.z.so
│   ├── napi_init.cpp               // NAPI 注册与参数桥接（Promise 化异步任务）
│   ├── node_probe.cpp              // IsNodeTypeSupported 全 14 类型探测
│   ├── suite_pipeline.cpp          // 离线 EDIT 管线（降噪）+ 格式转换器（26.0.0）
│   ├── realtime_pipeline.cpp       // 实时 REALTIME 管线（空间渲染/EQ）+ OH_AudioRenderer
│   ├── pcm_source.cpp              // rawfile WAV 解析 + 程序合成（棕噪声/440Hz 正弦）
│   └── types/libentry/Index.d.ts   // ArkTS 侧类型声明
├── ets/
│   ├── pages/Index.ets             // 四 Tab 主框架
│   └── features/
│       ├── model/WorkshopMock.ets  // Mock 素材/成品（与真实链路物理隔离）
│       └── workbench/
│           ├── WorkbenchView.ets   // 加工台：五块真实功能区 + 500ms 轮询
│           └── model/AudioSuiteErrorMap.ets  // 管线 0–13 + 转换器 0–8 + 本地负值码分域路由
└── resources/rawfile/
    ├── voice_noisy.wav             // 带噪人声 48k/S16LE/2ch（降噪实测素材）
    └── brown_noise.wav             // 棕噪声 8.0s（空间渲染素材）

3、Kit能力与核心API深度解析

3.1 先选型：端侧做效果加工，三条路摆一遍

动手前我把「在鸿蒙端侧给 PCM 加效果」的可行路径列了表，结论直接决定工程量：

方案	能力面	实时性	主要代价
OHAudioSuite C 管线	12 种效果节点 + 离线/实时双模式，系统级实现	实时预览低延迟（回调驱动）	纯 C 接口，需 NAPI 桥接；五层句柄生命周期自己管
移植第三方算法库	取决于库本身	取决于实现	SIMD/线程调度全自理，包体与授权成本，效果质量无系统背书
云端处理回传	无端侧依赖	受网络制约	素材上行有隐私与流量成本，离线不可用

我的场景是「素材在本地、效果要可听可测」，云端方案直接出局；移植算法库的维护成本对一个演示工程不划算。OHAudioSuite 的系统级实现还带来一个隐性收益：效果节点的输出格式是官方固定的（降噪恒为 16k/S16LE/1ch），输出侧不需要自己做重采样。

播放侧回调接口还有一次小选型，值得单独记：

接口	状态	说明
OH_AudioStreamBuilder_SetRendererWriteDataCallback	现行（introduced 12）	回调返回 OH_AudioData_Callback_Result（VALID=0/INVALID），语义清晰
OH_AudioRenderer_Callbacks（旧结构体）	已废弃	网上老教程还在用，照抄会吃到废弃告警且后续版本有移除风险

3.2 三级模型与反向驱动渲染

OHAudioSuite 的结构是引擎 → 管线 → 节点。引擎统一管理管线（最多 10 条），管线分两种工作模式：离线编辑（EDIT=1）与实时预览（REALTIME=2）；节点三类：输入、效果、输出，节点不能独立存在，必须挂在管线上。

最反直觉的是数据流方向：渲染由输出侧反向驱动。应用调 OH_AudioSuiteEngine_RenderFrame() 发起一帧请求，输出节点向上游效果节点要数据，效果节点再向输入节点要，最终触发输入节点的 OH_InputNode_RequestDataCallback() 回调向应用索取 PCM——应用只负责往回调里喂数据，整条链的拉动权在系统手里。这个机制决定了两个编码习惯：输入回调里写的字节数可以小于请求量（返回值报实写），以及最后一批数据必须置 finished=true。

12 种效果节点与官方输出格式（本篇实测核对过降噪与空间渲染两行）：

效果	节点类型	起始 API	输出格式
均衡器	201	22	48000Hz/S16LE/2ch
降噪	202	22	16000Hz/S16LE/1ch（实测吻合）
声场	203	22	48000Hz/S16LE/2ch
音源分离	204	22	48000Hz/F32LE/4ch；依赖 NPU，只能连输出节点
声音美化 / 环境效果	205 / 206	22	48000Hz/S16LE/2ch
混音	207	22	F32LE/2ch，支持多路输入
空间渲染	208	23	48000Hz/S16LE/2ch（实测吻合）
传统变声 / 通用变声 / 变速变调	209 / 210 / 211	23	16k/1ch、48k/2ch、48k/1ch
HOA 空间音频	212	26.0.0 参考面新增	HOA 转双耳

硬约束几条，创建节点前背下来：每条管线至少 1 个输入节点、有且只有 1 个输出节点；输出节点 ≤1、混音 ≤3、音源分离 ≤1；输入节点与其余效果节点每类上限 API 24 前 5 个、24 起 15 个；创建前必须 OH_AudioSuiteEngine_IsNodeTypeSupported() 探测——音源分离依赖 NPU，探测是必选项不是可选项。

3.3 7.0 (API 26) 增量：格式转换器与参考面扩展

发布说明 Beta2 条目「新增基于 C/C++ 的音频格式转换能力」对应 native_audio_converter.h，接口四件套：OH_AudioConverter_Create（传入/输出格式）→ SetInputCallback（喂数据）→ Process（取结果）→ Destroy。三条官方语义直接决定写法：回调单次给数据 ≤400KB；输入给完后要再报一次 AUDIOCONVERTER_INPUT_DATA_FINISHED；即使回调已报 FINISHED，Process 仍须循环调用直到返回 SUCCESS 且 outputSize=0——最后一步是排空内部重采样缓存，提前退出会丢尾巴。

API 参考面同版本还有：HOA 节点 212、调试接口 OH_AudioSuite_PrintInfo()、channelLayout 从 MONO/STEREO 扩到 41 种、channelCount 扩到 1–9 及 16、实时预览管线数量限制取消（26.0.0 前实时管线最多 1 条，总数仍 ≤10）。本篇的实时演示只开一条实时管线，多实时管线并发留作后续实测。

4、逻辑流梳理

离线降噪的反向驱动渲染，一张图说清拉动关系：

实时预览的生命周期叠上 ArkTS 侧的轮询与销毁，箭头每一步都能在真机 hilog 里对上：

图上有两处是审查揪出来的真问题，都在 5.7 与第 6 节展开：回调里 Stop 必须用传入的 renderer 参数（全局句柄与主线程 Release 存在竞态）；轮询发现已停时必须显式销毁 native 会话（native 自动 Stop 只停 renderer，不释放管线/节点/引擎）。

5、项目实战

环境声明：HarmonyOS 7.0.0.107 (API 26) 正式版，DevEco Studio 26.0.0，Mate 60 Pro（ALN-AL80，麒麟 9000S），SDK 26.0.0；C++ 侧链接 libohaudio.so 与 libohaudiosuite.so。

5.1 离线降噪：组网与渲染循环

降噪管线三节点：输入（48k/2ch 素材格式）→ 降噪 202 → 输出（16k/S16LE/1ch，官方固定输出格式）。渲染循环是离线模式的核心，完成信号的判定在这里：

// 启动管线后循环渲染：finishedFlag=true 才是「全部处理完成」的信号
ret = OH_AudioSuiteEngine_StartPipeline(pipeline);
// ...错误检查省略，与工程一致
int32_t frameSize = RENDER_FRAME_DURATION_MS * task->outputSampleRate * 1 * S16LE_BYTE_SIZE
                    / MS_PER_SECOND;          // 离线侧 frameSize 是应用自定的缓冲字节数
std::vector<uint8_t> frame(static_cast<size_t>(frameSize));
int32_t responseSize = 0;
bool finished = false;
while (!finished) {                             // 退出条件只看 finished，不看单次返回值
    ret = OH_AudioSuiteEngine_RenderFrame(pipeline, frame.data(), frameSize,
                                          &responseSize, &finished);
    if (ret != AUDIOSUITE_SUCCESS) { fail("RenderFrame", ret); break; }
    if (responseSize > 0) {                     // 有数据就累积
        task->outputPcm.insert(task->outputPcm.end(), frame.data(),
                               frame.data() + responseSize);
        continue;
    }
    if (!finished) {                            // SUCCESS+0 字节+未完成 = 异常，不能当成功
        fail("RenderFrameEmptyResponse", -22);  // 否则拿截断数据算 RMS，文章数据就废了
        break;
    }
}
OH_AudioSuiteEngine_StopPipeline(pipeline);     // 销毁前置：DestroyNode 要求管线已停止

销毁顺序按官方来：节点 → 管线 → 引擎，构造器单独销毁。实测输出 974080 字节 = 30.44s × 16000Hz × 1ch × 2B（974080 ÷ 32000 = 30.44 整除）；UI 显示的素材时长 30.4s 是 WAV 头时长的四舍五入展示，951KB 是 974080 ÷ 1024 的取整——字节、时长、界面显示三者口径各自说清，互不冒充。

5.2 实时预览：回调、帧统计与帧长单位

实时模式把 RenderFrame 放进 renderer 的写数据回调里，系统线程每次回调拉动一帧。回调内做了帧耗时统计（无锁 CAS 更新最大值），文章按实测下结论：

static OH_AudioData_Callback_Result RtAudioRendererOnWriteData(OH_AudioRenderer *renderer,
                                                               void *userData, void *audioData,
                                                               int32_t audioDataSize) {
    bool finishedFlag = false;
    int32_t writeSize = 0;
    auto rfStart = std::chrono::steady_clock::now();
    // userData 即管线句柄（官方示例同款传递）：回调里反向驱动整条管线
    OH_AudioSuite_Result result = OH_AudioSuiteEngine_RenderFrame(
        static_cast<OH_AudioSuitePipeline *>(userData), audioData, audioDataSize,
        &writeSize, &finishedFlag);
    auto rfEnd = std::chrono::steady_clock::now();
    // 帧耗时统计：CAS 更新 max，超 20ms 预算计数——「预算够不够」用真机数据回答
    int64_t elapsedUs = std::chrono::duration_cast<std::chrono::microseconds>(rfEnd - rfStart).count();
    g_session.renderFrameCount.fetch_add(1);
    // ...CAS 更新 maxRenderUs / overBudgetCount 省略，与工程一致
    if (result != AUDIOSUITE_SUCCESS) {
        return AUDIO_DATA_CALLBACK_RESULT_INVALID;   // 本帧数据无效，不中断播放循环
    }
    if (finishedFlag) {
        // ⚠️ 用**传入的 renderer 参数** Stop：全局句柄可能与主线程 Release 竞态（见 6.3）
        OH_AudioRenderer_Stop(renderer);
    }
    return AUDIO_DATA_CALLBACK_RESULT_VALID;
}

帧长设置那一行是本次最大的坑，修正后的写法与注释：

// ⚠️ 单位坑：SetFrameSizeInCallback 参数单位是**采样点数**。OHAudio API 参考原文：
// 48kHz 下 20ms 对应 960 个采样点，回调字节长由系统按 960×声道×位深字节自动算出。
// 官方音频编创实时示例的公式（时长×采样率×声道×位深/1000）算出的是字节数 3840，
// 照抄会被系统当成 3840 个采样点 → 实际回调周期 80ms（真机佐证见 6.1）。
int32_t frameSize = RENDER_FRAME_DURATION_MS * PREVIEW_SAMPLE_RATE / MS_PER_SECOND; // =960
OH_AudioStreamBuilder_SetFrameSizeInCallback(g_session.rendererBuilder, frameSize);

5.3 格式转换器：排空循环

转换器同步调用即可（5 秒素材毫秒级完成）。输入回调按 ≤400KB 分块喂数据，喂完报 FINISHED；Process 循环到 SUCCESS 且 outputSize=0 才退出：

while (true) {                                  // 官方排空要求：FINISHED 后仍须循环
    int32_t outputSize = 0;
    ret = OH_AudioConverter_Process(converter, outBuf.data(), capacity, &outputSize);
    if (ret != AUDIOCONVERTER_SUCCESS) { errorCode = ret; errorStage = "Process"; break; }
    if (outputSize == 0) { break; }             // 缓存排空，正常结束
    outputPcm.insert(outputPcm.end(), outBuf.data(), outBuf.data() + outputSize);
}
// 与工程一致，此处省略 Create/SetInputCallback 的错误分流与 Destroy 配对

实测 882000 → 960000 字节，比值 1.088435… 与 48000/44100 逐位吻合，两侧时长均 5.000s——重采样没有丢时间轴。

5.4 ArkTS 侧：轮询与会话清理

native 回调在系统线程，不能直接更新 @State（篇 1 踩过的响应式坑直接复用结论），播放进度用 500ms 轮询读 native 状态；轮询发现已停时显式销毁会话：

this.pollTimer = setInterval(() => {
  const playing: boolean = isRealtimePlaying();
  const sec: number = getRenderedSeconds();
  this.renderedSeconds = sec;
  if (!playing) {
    // 素材播完时 native 只自动 Stop renderer，管线/节点/引擎还在——必须显式销毁，
    // 否则 active 会话滞留（审查揪出的泄漏，见 6.4）。顺带读帧统计供实测口径。
    this.renderStats = getRenderStats();
    stopRealtimePreview();
    this.playingEffect = '';
    this.clearPoll();
  }
}, 500);

5.5 运行时遇到的三个真问题

代码写完跑了一轮遇到几个问题：

• 回调与销毁竞态（critical）：写数据回调里用全局 g_session.renderer 调 Stop，与主线程 DestroySession 的 Release 存在竞态，极端时序下 Stop 到已释放句柄。修复改用回调传入的 renderer 参数——系统保证本次回调期间该句柄有效。审查同时建议加互斥锁，我推演后否决：Release 本身会等回调排空，回调再拿同一把锁即死锁。
• 自然播完会话泄漏：素材播完 native 自动 Stop renderer，ArkTS 轮询只清 UI 不调 stop，aboutToDisappear 又被 playingEffect=='' 短路——五层句柄与 PCM 缓冲滞留到下次启动。修复即 5.4 的轮询分支补销毁 + aboutToDisappear 无条件清理。
• 异步任务挂死：降噪走 napi_async_work，创建/入队失败时 Promise 永久 pending 且任务对象泄漏。补状态检查：失败即 reject + delete。

5.6 真机实测数据汇总

场景	实测数据	自洽校验
节点探测	14 类型全 supported（含 NPU 依赖的 204、新增 212）	与 API 26 参考面一致
离线降噪	RMS -16.91 → -18.22 dBFS；渲染 4479ms；输出 974080B	974080 = 30.44s×16k×1ch×2B（整除）
空间渲染（修正后）	8.0s 素材 RenderFrame 400 次、max 2.31ms、超 20ms 预算 0 次	400 = 8.0s ÷ 20ms 理论值
EQ 播放中切预置	preset=8 → preset=2 均 ret=0，听感即时变化	验证实时模式参数热更新
格式转换	882000 → 960000B，34ms	比值 1.0884 = 48000/44100
会话生命周期	播完自动 Stop → 轮询销毁 → hilog「会话销毁：帧统计 count=400」	无句柄滞留

摘三条日志原文（时间戳/进程/线程号保留，RMS 与耗时数值被 hilog 隐私机制掩码为 <private>，数值以截图 UI 为准）：

09-20 17:56:36.482  3467  3467 I A00000/com.qingkouwei.lightdeck/LightDeck.RealtimePipeline: 实时预览启动：effect=space_render，PCM 1536000 字节
09-20 17:56:44.323  3467  3902 I A00000/com.qingkouwei.lightdeck/LightDeck.RealtimePipeline: 预览素材播放完毕，renderer 已停止（帧 max=2315μs 超时0次）
09-20 17:56:44.500  3467  3467 I A00000/com.qingkouwei.lightdeck/LightDeck.RealtimePipeline: 会话销毁：帧统计 count=400 max=2315μs 超预算=0

官方来源定位：版本增量出自官方《OS 新增和增强特性（26.0.0）》Audio Kit 章节（Beta2「新增基于 C/C++ 的音频格式转换能力」）；帧长单位出自 OHAudio API 参考 native_audiostreambuilder.h 的 OH_AudioStreamBuilder_SetFrameSizeInCallback 条目（「48000Hz 时，20ms 音频数据对应的帧长计算方式为 frameSize = 48000 × 0.02，即 960 个采样点数」）；示例公式出自开发指南《音频编创·实时预览（C/C++）》；管线函数名（OH_AudioSuiteEngine_RenderFrame 首参为 pipeline 句柄）以本机 SDK 26.0.0 头文件 ohaudiosuite/native_audio_suite_engine.h 第 203 行声明为准。

剩余假设：以上均为麒麟 9000S + 7.0.0.107 正式版上的可重复观察；HOA 节点缺素材只做了探测未做听感实测；多实时管线并发（26.0.0 解禁项）未测；PC/2in1 形态待验证。

6、避坑指南

6.1 SetFrameSizeInCallback 的单位：示例公式与接口文档口径不一致

• 现象：帧耗时统计上线后，8.0s 素材只记到 100 帧、30.4s 素材只记到 381 帧——约为理论值（时长÷20ms）的四分之一。播放听感正常，没有任何报错。
• 根因：OHAudio API 参考写明 frameSize 单位是采样点数（48kHz 下 20ms = 960，回调字节长由系统按 960×声道×位深自动算出）；而官方音频编创实时预览示例的帧长公式算出的是字节数 3840。把 3840 当采样点传入，回调周期变成 3840÷48000 = 80ms——100 帧 × 80ms = 8.0s、381 × 80ms ≈ 30.5s，两组真机数据与 80ms 周期精确吻合，证据闭环。
• 方案对比：照抄示例公式（80ms 周期，仍在官方普通通路 20–100ms 允许范围内，能跑但注释与 UI 文案失真）／按 OHAudio 文档传采样点 960（真 20ms）／不设置用系统默认（周期不可控，帧预算无从谈起）。
• 最佳实践：按采样点数传 时长ms × 采样率 / 1000，并在注释里写明单位来源；帧预算结论一律以实测帧数÷时长反推周期后下。
• 验证：修正后真机复测 8.0s 素材 RenderFrame 400 次（= 理论值）、max 2.31ms、超预算 0 次；hilog 与 UI 显示一致。

6.2 RenderFrame 的完成信号是 finishedFlag，不是 SUCCESS

• 现象：首版渲染循环以「返回 SUCCESS」为退出条件之一，审查指出 SUCCESS + responseSize=0 + 未 finished 的组合会被当成正常结束。
• 根因：头文件语义为「管线尽力填充，finishedFlag=true 才是全部处理完成的信号」；0 字节只表示本帧无数据可给。
• 方案对比：SUCCESS 即退出（拿截断数据算 RMS，数据 silently 错）／只看 finishedFlag + 0 字节继续循环（离线 EDIT 模式理论上不该出现空响应，出现即异常）／0 字节且未 finished 判失败（-22 本地码，显式暴露）。
• 最佳实践：while(!finished) 为唯一退出条件；空响应走显式失败分支，宁可报错不拿脏数据。
• 验证：降噪输出 974080B 与素材时长、格式三方自洽，RMS 有值且可复现。

6.3 回调里 Stop 用传入参数，别碰全局句柄

• 现象：审查标记 critical——写数据回调用全局 g_session.renderer 调 Stop，与主线程 DestroySession 的 Release 竞态。
• 根因：全局指针可能在回调执行期间被主线程释放；回调参数由系统在本次回调期间保证有效。
• 方案对比：加互斥锁串行化（推演死锁：Release 等回调排空、回调等同一把锁）／用传入的 renderer 参数（零额外同步，语义正确）。
• 最佳实践：系统线程回调里只使用回调参数与 C++ 侧原子状态，不读全局句柄、不碰 JS/napi 对象。
• 验证：修复后多轮「播完自动停 + 手动停 + 页面退出」组合操作无崩溃，hilog 每次都有完整「会话销毁」记录。

6.4 自然播完 ≠ 会话释放

• 现象：素材播完 UI 回「未播放」，但 native 管线/节点/引擎与 PCM 缓冲仍驻留，直到下次启动才被覆盖。
• 根因：native 自动 Stop 只停 renderer；ArkTS 轮询分支只清 UI 状态，aboutToDisappear 被空播放态短路。
• 方案对比：依赖页面析构清理（被短路，不可靠）／轮询分支补 stopRealtimePreview + native 侧 active 标志幂等（双保险）／native 自动释放（接口无此语义，不可行）。
• 最佳实践：播放结束的判定与销毁放在同一分支；native 销毁函数做幂等，允许重复调用。
• 验证：hilog「会话销毁：帧统计 count=… 」在每次播完/手动停/退页后均出现，帧计数与 UI 一致。

另记两个小坑：转换器错误码（0–8）与管线错误码（0–13）数值重叠，ArkTS 侧必须按来源分域路由到不同文案表，靠码值大小区分会串味；节点探测失败（查询接口报错）不能呈现为「不支持」，否则污染文章数据，工程里用独立 queryError 字段做三态显示。

7、总结

这篇把「音频效果加工」从 PC 插件宿主搬到了鸿蒙端侧：选型上 OHAudioSuite 以系统级实现 + 固定输出格式胜出；机制上吃透了反向驱动渲染——应用只喂数据，拉动权在系统；版本上守住纪律，底座（API 22/23）与 7.0 增量（格式转换器、HOA、多声道、实时管线解禁）分开陈述。实测层面，降噪字节自洽、环绕帧预算 0 超、转换比值逐位吻合，三个「数字对得上」比任何形容词都硬。

最大的教训是 6.1：官方示例与接口文档口径不一致时，真机数据是唯一的仲裁者。100 帧对 400 帧的差异没有报任何错，听感也正常，只有把帧数÷时长反推周期这一步做出来，坑才现形。写端侧音频的同学，拿到帧统计先做这个除法。

已知边界：HOA 节点仅探测未实测听感；多实时管线并发未测；音源分离 204 本机 supported 但未跑双路输出链路；界面为演示级排版，产品级视觉在后续迭代；PC/2in1 形态待验证。