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);
#endiffor (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;} elseWARN_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, &param);

即可加入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，后面就不表了，以后再说吧~