您现在的位置是:首页 >技术交流 >ALSA子系统(十八)------指纹解锁动画提示声卡顿问题解析网站首页技术交流
ALSA子系统(十八)------指纹解锁动画提示声卡顿问题解析
你好!这里是风筝的博客,
欢迎和我一起交流。
很久没写kernel相关的东西了,主要是来到手机厂之后,大部分还是在Android上,Kernel虽然也有涉及,但毕竟只是有所涉及,主要业务逻辑还是在HAL之上,kernel的修改除了项目bringup,之后基本甚少修改。
最近倒是碰到一个Kernel的问题,简单记录下~
【前提条件】【Prerequistes】手机录入指纹 声音与振动——触感与提示音开启指纹动画音, 指纹样式选择旋涡样式
【操作步骤】【Operation steps】播放QQ音乐,按power键息屏亮屏指纹解锁
【实际结果】【Actual results】指纹动画声音响起有卡顿声
【期望结果】【Expected results】不应该有卡顿声音
【对比的上个版本编号】【Number of previous version for comparison】低概率问题
以我多年工作经验来看,外放问题是最好解决的了,相对好处理些。
查看AudioDspStreamManager.xx.TaskPlayback_ivdump.pcm文件,这是PA的VI反馈信号,可以反馈出喇叭的真实状态。从频谱上看,确实出现了卡顿,在解锁动画提示音响起的时候。
同样查看AudioDspStreamManager.xx.TaskPlayback_datain.pcm,发现确实Kernel里的数据就有问题了,但是查看streamout.pcm.xx.AudioALSAPlaybackHandlerDsp.flag8.xx.48000.8_24bit.2ch_20230411_092109.wav
是没有问题的,说明问题出现在了Kernel底层,没有出现在HAL。
因为提示音是短音,走的fast通路,buf又小,确实容易出现问题。
查看kernel log:
<6>[83150.878119][T600541] mtk_dsp_check_exception() deep adsp underflow
<6>[83150.926100][T516896] snd_audio_dsp snd_audio_dsp: mtk_dsp_start() deep just underflow
<6>[83178.409440][T700541] mtk_dsp_check_exception() fast adsp underflow
<6>[83178.419408][T712585] snd_audio_dsp snd_audio_dsp: mtk_dsp_start() fast just underflow
确实发现了异常,出现了underflow,这表明写数据慢了,没有数据可以播放,所以出现了underflow!
同步查看ADSP的log:
[83137.343]<A-22>[D]audio_dsp_hw_write_op(), HW_STATE_UNDERFLOW, return
[83157.758]<A-11>[D] enter_write_cond, underflow, written_size[2048] datacount[0] task_name[fast_playback]
[83157.758]<A-11>[W] write_data_loop() ADSP_DL_CONSUME_UNDERFLOW
[83166.654]<A-11>[D] enter_write_cond, underflow, written_size[2048] datacount[0] task_name[fast_playback]
[83166.654]<A-11>[W] write_data_loop() ADSP_DL_CONSUME_UNDERFLOW
确实同样可以看到underflow。
因为underflow是没有数据可播,属于写数据不及时,所以修改增大buffer size是没有用的。
所以我们只能另想它法!
这里简单描述下MTK的播放:
灵魂画手,嘿嘿,按照理解自己画了下图~
Hal往kernel写数据之后,会通过ipi核间通信,将数据送往DSP做处理,DSP上会跑我们用到的算法,处理完的数据就通过iis送到codec进行播放,kernel里面只负责管理对codec的control。
源码解析:
drivers/misc/mediatek/audio_ipi/common/adsp_ipi.c
static int __init audio_ipi_init(void)
{
ipi_queue_init();
audio_task_manager_init();
audio_messenger_ipi_init();
init_audio_ipi_dma();
#if IS_ENABLED(CONFIG_MTK_AUDIODSP_SUPPORT)
adsp_register_notify(&audio_ctrl_notifier);
#endif
for (task_id = 0; task_id < TASK_SCENE_SIZE; task_id++) {
task_info = &g_audio_task_info[task_id];
dsp_id = audio_get_dsp_id(task_id);
task_info->dsp_id = dsp_id;
task_info->is_dsp_support = is_audio_dsp_support(dsp_id);
task_info->is_adsp = is_audio_use_adsp(dsp_id);
task_info->is_scp = is_audio_use_scp(dsp_id);
task_info->task_ctrl = get_audio_controller_task(dsp_id);
}
ret = misc_register(&audio_ipi_device);
}
drivers/misc/mediatek/audio_ipi/common/adsp_ipi_queue.c
void ipi_queue_init(void)
{
for (dsp_id = 0; dsp_id < NUM_OPENDSP_TYPE; dsp_id++) {
if (is_audio_dsp_support(dsp_id))
ipi_queue_init_by_dsp(dsp_id);
}
#if IS_ENABLED(CONFIG_MTK_AUDIODSP_SUPPORT)
hook_ipi_queue_send_msg_handler(dsp_send_msg_to_queue_wrap);
hook_ipi_queue_recv_msg_hanlder(dsp_dispatch_ipi_hanlder_to_queue_wrap);
#endif
}
hook_ipi_queue_send_msg_handler和hook_ipi_queue_recv_msg_hanlder主要是给ipi_queue_send_msg_handler和ipi_queue_recv_msg_handler这两个函数指针赋值的,在给dsp发送msg和接受msg的时候会用,这里没啥好说的,主要是:ipi_queue_init_by_dsp,这里会针对DSP做初始化:
int ipi_queue_init_by_dsp(uint32_t dsp_id)
{
for (dsp_path = 0; dsp_path < DSP_NUM_PATH; dsp_path++) {
msg_queue = &g_dsp_msg_queue[dsp_id][dsp_path];
ret = dsp_init_single_msg_queue(msg_queue, dsp_id, dsp_path);
if (ret != 0)
WARN_ON(1);
}
}
这里会循环两次:0是AP to DSP,1是DSP to AP。
static int dsp_init_single_msg_queue(
struct dsp_msg_queue_t *msg_queue,
const uint32_t dsp_id,
const uint32_t dsp_path)
{
if (dsp_path == DSP_PATH_A2D) {
msg_queue->dsp_process_msg_func = dsp_send_msg_to_dsp;
} else if (dsp_path == DSP_PATH_D2A) {
msg_queue->dsp_process_msg_func = dsp_process_msg_from_dsp;
} else
WARN_ON(1);
/* lunch thread */
msg_queue->dsp_thread_task = kthread_create(
dsp_process_msg_thread,
msg_queue,
"%s",
thread_name);
if (IS_ERR(msg_queue->dsp_thread_task)) {
pr_info("can not create %s kthread", thread_name);
WARN_ON(1);
msg_queue->thread_enable = false;
} else {
msg_queue->thread_enable = true;
dsb(SY);
wake_up_process(msg_queue->dsp_thread_task);
}
}
重点看下这里面就好了,针对不同的情况,AP to DSP 还是 DSP to AP,会赋值不同的处理函数到dsp_process_msg_func。然后会创建线程:dsp_process_msg_thread,并启动:wake_up_process
static int dsp_process_msg_thread(void *data)
{
while (msg_queue->thread_enable && !kthread_should_stop()) {
/* wait until element pushed */
retval = dsp_get_queue_element(msg_queue, &p_dsp_msg, &idx_msg);
p_element = &msg_queue->element[idx_msg];
/* send to dsp */
retval = msg_queue->dsp_process_msg_func(msg_queue, p_dsp_msg);
/* notify element if need */
spin_lock_irqsave(&p_element->element_lock, flags);
if (p_element->wait_in_thread == true) {
p_element->send_retval = retval;
p_element->signal_arrival = true;
dsb(SY);
wake_up_interruptible(&p_element->element_wq);
}
spin_unlock_irqrestore(&p_element->element_lock, flags);
/* pop message from queue */
spin_lock_irqsave(&msg_queue->queue_lock, flags);
dsp_pop_msg(msg_queue);
spin_unlock_irqrestore(&msg_queue->queue_lock, flags);
}
return 0;
}
线程里面处理还是比较简单的,就是等待有数据到queue里,如果有就通过之前填充的dsp_process_msg_func钩子函数,发给DSP处理即可。
好,扯了这么一大堆,回归本题,如果出现了underflow,说明写数据不及时,写数据就是通过dsp_process_msg_thread这个线程里面写到DSP的,所以,我们只需要保证这个线程的正常调度运行即可。
如何保证呢?自然是提升线程优先级!
为了使得用户能有良好的用户体验,dsp_init_single_msg_queue这里在创建线程的时候,这里直接将线程加入RT线程,RT (Real Thread)实时线程。
kthread_create线程创建之后,通过这个API:
struct sched_param param = { .sched_priority = 3 };
sched_setscheduler_nocheck(msg_queue->dsp_thread_task, SCHED_FIFO, ¶m);
即可加入RT线程。
加入RT线程之后,压测问题场景,没有再出现underflow的情况,卡顿问题也没有再复现了,问题完美解决~
最开始的audio_ipi_init函数里,还有一些内容就不多阐述了,DSP这块资料比较少,还是比较难去了解的,非本文重点。
audio_ipi_init后面就是配置DMA和TASK这些,每个scene占用一个Task:
/* scene for library */
TASK_SCENE_PHONE_CALL = 0,
TASK_SCENE_VOICE_ULTRASOUND = 1,
TASK_SCENE_PLAYBACK_MP3 = 2,
TASK_SCENE_RECORD = 3,
TASK_SCENE_VOIP = 4,
TASK_SCENE_SPEAKER_PROTECTION = 5,
TASK_SCENE_VOW = 6,
TASK_SCENE_PRIMARY = 7,
TASK_SCENE_DEEPBUFFER = 8,
TASK_SCENE_AUDPLAYBACK = 9,
TASK_SCENE_CAPTURE_UL1 = 10,
TASK_SCENE_A2DP = 11,
//......
OK,后面就不表了,以后再说吧~