On Thu, Jun 14, 2018 at 5:48 PM, noman pouigt <variksla@xxxxxxxxx> wrote: > On Thu, Jun 14, 2018 at 3:42 AM, Mark Brown <broonie@xxxxxxxxxx> 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: > 1. 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? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
