[PATCH] ASoC: Intel: Atom: use hardware counter to update hw_ptr

[Lu, Brent]

> 
> All the Atom firmware assumes data chunks in multiples of 1ms (typically 5,
> 10 or 20ms). I have never seen anyone use 256 frames, that's asking for
> trouble really.
> 
> it's actually the same with Skylake and SOF in most cases.
> 
> Is this a 'real' problem or a problem detected by the Chrome ALSA
> compliance tests, in the latter case that would hint at a too generic value of
> min_period.
> 

I've told them 240 is more reasonable since the sample rate is 48000 and our
android bsp also uses 240 for multimedia use case for many years but they don't
want to change the CRAS setting for some reason.

Google says it's a real issue for them: "The driver consumes frames quickly at the
beginning will make CRAS underrun because CRAS fills samples in the fixed rate."

Currently they implement constraint in machine driver of atom machines to force
240 period size so CRAS is using 240 for atom platforms and 256 for other big cores.

I'm curious why not just using hardware counter to update hw_ptr and get rid of
the period setting in hw_param? It seems to me the ring buffer counter does not
reflect the real status.


Regards,
Brent

> 
> and that seems also wrong? Why would the delay be zero?
> 

info->pcm_delay is the difference between ring buffer counter and hardware
counter. Because the ring buffer counter (hw_ptr) is running faster then it should,
so we add the info->pcm_delay to substream->runtime->delay as compensation.

Therefore, application could use snd_pcm_delay() to get the actual frame number
which are still in buffer.

snd_pcm_delay() = buffer_size - snd_pcm_avail() + runtime->delay

We don't need pcm_delay to compensate anything if using hardware counter.


> > -	info->pcm_delay = delay_frames;
> >   	dev_dbg(ctx->dev, "buffer ptr %llu pcm_delay rep: %llu\n",
> >   			info->buffer_ptr, info->pcm_delay);
> >   	return 0;
> >