On Thu, Jun 14, 2018 at 5:48 PM, noman pouigt variksla@gmail.com wrote:
On Thu, Jun 14, 2018 at 3:42 AM, Mark Brown broonie@kernel.org wrote:
On further debugging I found that I am getting xruns which explains the problem.
I am getting xrun in elapsed callback and ALSA is sending kill_fasync to userspace and userspace is calling prepare and trigger callback again.
I think I can check XRUN condition in prepare callback and send userspace a error to let them know that XRUN happened.
On Thu, Jun 14, 2018 at 02:12:35AM -0700, noman pouigt wrote:
I have also used high priority workqueues but that didn't help either. Wondering if I can get some pointers to debug this? also if there any alsa-utility which can simulate closely audio flinger?
You probably just need to ensure that you've got more than one period so there's always one ready, increase min_periods or possibly make the individual periods bigger. It's normally going to be very hard to get everything scheduled reliably if there's no margin for error, ensuring there's some grace in case things run over will tend to be more robust.
Thanks, but can you kindly explain how userspace application read which is happening via pcm_read (mmap) affects kernel SPI workqueue thread doing SPI read in a while loop i.e. causing SPI reads to get delayed?
In kernel, we have two workqueues:
- First to do SPI reads after trigger callback trigger and call
elapsed callback once SoC gets more than period size. 2. Second to handle interrupts from DSP.
First workqueue SPI reads is getting delayed based on the what application is reading data. In case of tinycap, we don't see much time difference between SPI reads but with AudioFlinger we see lot of time difference between consecutive SPI reads? How can application affect kernel threads and cause this delay?
Please let me know where is this dependency coming from?