[alsa-devel] [PATCH v2 09/11] ASoC: Intel: Skylake: Fix DMA position reporting for capture stream
Takashi Iwai
tiwai at suse.de
Mon Mar 27 15:12:02 CEST 2017
On Mon, 27 Mar 2017 12:29:54 +0200,
Vinod Koul wrote:
>
> On Sat, Mar 25, 2017 at 02:21:13AM +0530, Ughreja, Rakesh A wrote:
> > >> >Are these workarounds needed for the legacy driver?
> > >> >If yes, which chips require it?
> > >> >
> > >>
> > >> Yes, these are needed in legacy driver as well.
> > >> From SKL and BXT onwards, it is needed.
> > >
> > >OK, thanks for confirmation.
> > >
> > >Now, from what I read in the above, is the workaround required *only*
> > >after the interrupt is generated? 20us delay isn't so cheap, and we
> > >tend to inquire PCM positions often. If the workaround is needed only
> > >after the PCM period elapse, we can set some flag in the irq handler
> > >and apply the workaround only when necessary.
> > >
> >
> > Yes, Takashi the workaround is required only in the period elapsed
> > interrupt. In some cases the DMA Position updates are delayed and so
> > when the period elapsed interrupt occurs the wait_for_avail thinks that
> > one period worth of data is not available and so returns only on the
> > next period elapsed interrupt. This creates problem for 2 periods
> > playback/capture streams.
> >
> > So even in the period elapsed interrupt the wait is required only if the
> > position is less than the period boundary.
>
> Hi Takashi,
>
> So we need this for 2 periods when the device is in irq mode. Not for other
> cases. ie SKL_PLUS..
Yeah, thanks. I'd cook a couple of patches to do that for the legacy
driver. But I still wonder whether the wait is always needed.
Judging from the description, does the discrepancy of posbuf read
happen *only* when the DMA position goes across the BD boundary?
Or does it happen at any time?
When you trace, you can see that the apps frequently inquires the
position. So, an unconditional wait should be really avoided.
> But have you seen any user reports on this till now.
I've seen some bug reports mentioning about crackling audio capture on
SKL (I forgot URLs). It might be triggered by that.
thanks,
Takashi
More information about the Alsa-devel
mailing list