demo 普遍使用 while(1) 且 deinit 路径不可达：录音调用 Liot_AudioDeInit 后设备复位

[zack3812]

问题概述

当前 examples/demo/src 中较多 demo 使用常驻 while (1) 驱动业务，而没有通过 queue、flag、semaphore 等 RTOS 原语接收退出事件并完成资源回收。

以 demo_sound.c 为例，Liot_AudioDeInit() 和任务删除位于无限循环之后，正常控制流不可达：

CAT1.bis_OpenCPU/examples/demo/src/demo_sound.c

Lines 6349 to 6367 in e3c57c6

	while(1)
	{
	#ifdef TEST_PLAY
	liot_trace("Audio Play ...");
	Liot_AudioPlay(audio16k_16, sizeof(audio16k_16)); //46384
	Liot_AudioWaitPlayFinish(LIOT_WAIT_FOREVER);
	#endif
	#ifdef TEST_RECORD
	liot_trace("Audio Record ...");
	Liot_AudioRecord(audioRecord, TEST_CACHE_LEN);
	Liot_AudioPlay(audioRecord, TEST_CACHE_LEN); //46384
	Liot_AudioWaitRecordFinish(LIOT_WAIT_FOREVER);
	#endif
	}
	liot_trace("Audio DeInit");
	Liot_AudioDeInit();
	liot_rtos_task_delete(0); // kill itsel

我在将录音 demo 接入实际业务、通过外部事件退出并执行音频去初始化时，设备发生了重启复位。因此想确认：这些 demo 中展示的 deinit 路径是否做过真实可达的真机验证？

当前代码中的疑问

1. examples/demo/src 当前约有 76 个 C 文件，其中 41 个文件存在常驻 while (1)，共约 48 处。对于需要停止、切换页面或重复初始化的能力，demo 没有展示如何通过 RTOS queue/flag/semaphore 安全退出任务。

2. demo_sound.c 和 demo_tts.c 的清理代码位于无限循环之后，按原始 demo 无法执行，因此无法证明 deinit 路径已被验证。

3. 录音分支当前调用顺序是：

   • Liot_AudioRecord(...)
   • Liot_AudioPlay(audioRecord, ...)
   • Liot_AudioWaitRecordFinish(LIOT_WAIT_FOREVER)

   这里在等待录音完成前就开始播放录音缓冲区，请确认该顺序是否符合音频驱动的预期生命周期。

4. demo 基本未检查 Liot_AudioInit、Liot_AudioRecord、Liot_AudioWaitRecordFinish、Liot_AudioStop、Liot_AudioDeInit 的返回值，也没有展示超时和失败后的逆序清理。

5. Liot_AudioWaitRecordFinish(LIOT_WAIT_FOREVER) 是否适合作为推荐用法？如果录音完成事件丢失或驱动状态异常，任务将无法进入清理流程。

实际现象

• 场景：录音功能退出/去初始化
• 操作：录音结束后，业务任务进入退出流程并调用 Liot_AudioDeInit()
• 实际结果：设备重启复位
• 期望结果：录音停止，音频相关任务、队列、I2S/I2C/codec/PA 等资源按顺序释放，函数返回明确结果，设备不复位

此前 #9 已报告 TTS 按 demo 方法去初始化会复位重启，但该 Issue 已关闭，回复未说明 deinit 的正确调用顺序或验证结果：

#9

本 Issue 补充的是录音场景，并希望确认所有相关 demo 的退出和资源生命周期设计。

希望维护者确认

1. Liot_AudioDeInit() 在调用前是否必须先调用 Liot_AudioStop()？
2. 停止录音后，是否还需要等待特定 callback/event、延时或底层任务退出，才能 deinit？
3. Liot_AudioDeInit() 能否在发起录音的同一任务中调用？是否有任务上下文或回调上下文限制？
4. Liot_AudioWaitRecordFinish()、Liot_AudioStop()、Liot_AudioDeInit() 的推荐顺序和超时策略是什么？
5. deinit 是否支持重复调用，以及 init -> record -> stop -> deinit -> init 的重复生命周期？
6. 当前发布版本中，播放、录音、TTS 等模块的 deinit 是否均已做过真机验证？如已验证，希望提供测试组合和结论。

建议改进

• 将至少一个音频 demo 改为可退出示例：使用 RTOS queue/flag 接收停止事件，而不是不可退出的 while (1)。
• 给出完整且可达的 init -> work -> stop/wait -> deinit -> task exit 流程。
• 所有等待设置有限超时，检查并打印关键 API 返回值。
• 文档明确资源所有权、正确退出顺序、允许调用的任务上下文和重复初始化约束。
• 对播放、录音、TTS 分别补充真机 deinit/重复初始化回归测试，避免示例中的清理代码长期处于不可达状态。

如果需要，我可以继续补充复位日志、具体模组/板卡型号和最小复现代码。