Hi all I am working on a realtime audio application on the rk3288 platform. I am using stable kernel 5.13.13. I'm using the open source tracy profiler to profile my application. My development PC receives trace data via ethernet from my platform. I have custom alsa drivers on my platform for my DACs and ADCs. My application has a thread in which I use snd_pcm_readi which blocks until it can read enough samples. I have another thread in which I write the samples to disk (sandisk extreme SD card). I use a ring-buffer so the code is lock-free. I've noticed that over a timespan of a few minutes I get a few clicks, which seem to come from the thread blocking on snd_pcm_readi not waking up in time. I am observing this in the traces I collect via tracy. Right before this happens, I can see kworker/kblockd being scheduled on one of the cores many times and rapidly, or ocasionally ksoftirqd, mmc_complete, or events_highpri. From the trace I collect, i have the impression nothing is being scheduled on the other cores, so I do not see a reason why my thread should not be woken up and scheduled. Why is the thread blocking on snd_pcm_readi not waking up in time, and is it possible that the kworker threads are preventing this, and why? Any suggestions on how to debug this further are greatly appreciated. Thanks Bert
