esp-skainet
esp-skainet copied to clipboard
语音识别时候,cpu 空跑耗电问题 (AIS-1160)
目前唤醒探测和命令识别的两个 task,一个 detect task 一个 feed task 都是在那不停地 i2s_read 和 fetch 数据,也没任何延迟,感觉太耗 cpu,会有两个问题。。
- 很容易触发 sr ring buffer 满了丢数据,如果 detect task 过慢的话
- 太过耗电,如果接的是电池,常开的话,感觉电池撑不了多久
问题1, 我这可以自己优化下。
问题2, 暂时没想到好办法,有啥好的优化建议吗?
可以尝试使用vad来降低功耗,AFE 的返回值有每一帧vad的状态,你可以根据这个状态来选择disable或enable 唤醒和命令词识别模型的运行。
可以尝试使用vad来降低功耗,AFE 的返回值有每一帧vad的状态,你可以根据这个状态来选择disable或enable 唤醒和命令词识别模型的运行。
现在的问题是,这个 afe->fetch 是在不停的 while loop 跑的。。而 vad 状态也是需要先 fetch 完,才能知道当前的实际状态,但是也没法根据这个状态去禁用 feed 或者下次的 fetch 。。。即使不说话,还是要不停的空跑 fetch loop 的。。这个空跑本身就很耗 cpu 吧。。我也没看到有加 delay,而且加了延时容易堵
如果我把 fetch 也放进 feed task 里面,进行快速检测,如果 vad 状态有人声,才去走 semphore 通知 fetch task 做识别,会有改善么,平常情况下 fetch task 处于 semphore wait 状态?
可以尝试使用vad来降低功耗,AFE 的返回值有每一帧vad的状态,你可以根据这个状态来选择disable或enable 唤醒和命令词识别模型的运行。
现在的问题是,这个 afe->fetch 是在不停的 while loop 跑的。。而 vad 状态也是需要先 fetch 完,才能知道当前的实际状态,但是也没法根据这个状态去禁用 feed 或者下次的 fetch 。。。即使不说话,还是要不停的空跑 fetch loop 的。。这个空跑本身就很耗 cpu 吧。。我也没看到有加 delay,而且加了延时容易堵
确实如此,fetch loop是停不下来的。 你可以用 afe->disable_wakenet() 和 afe->disable_aec() 来临时地关闭一些afe模块,但功耗应该降低的不明显。 如果想明显降低功耗,需要配合降低CPU的频率,或是直接关闭CPU(目前esp32s3不支持)
如果我把 fetch 也放进 feed task 里面,进行快速检测,如果 vad 状态有人声,才去走 semphore 通知 fetch task 做识别,会有改善么,平常情况下 fetch task 处于 semphore wait 状态?
改善不明显,需要配合降低CPU的频率
如果我把 fetch 也放进 feed task 里面,进行快速检测,如果 vad 状态有人声,才去走 semphore 通知 fetch task 做识别,会有改善么,平常情况下 fetch task 处于 semphore wait 状态?
改善不明显,需要配合降低CPU的频率
怎么降低?有相关 api 吗?如果vad 状态检测到人声,在调高 cpu 频率?
而且 cpu频率低了。。feed/fetch 空数据空跑的也变了慢了,会不会跟不上处理导致 sr ring buffer 经常满了,或者响应变慢
如果我把 fetch 也放进 feed task 里面,进行快速检测,如果 vad 状态有人声,才去走 semphore 通知 fetch task 做识别,会有改善么,平常情况下 fetch task 处于 semphore wait 状态?
改善不明显,需要配合降低CPU的频率
通过配置一块低功耗的CPU能解决这个问题吗?在检测状态时,关闭主CPU,只用低功耗CPU进行检测。
如果我把 fetch 也放进 feed task 里面,进行快速检测,如果 vad 状态有人声,才去走 semphore 通知 fetch task 做识别,会有改善么,平常情况下 fetch task 处于 semphore wait 状态?
改善不明显,需要配合降低CPU的频率
通过配置一块低功耗的CPU能解决这个问题吗?在检测状态时,关闭主CPU,只用低功耗CPU进行检测。
会不会影响唤醒 敏感度?比如等个几秒才响应