Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: X9g2b5GFZoRBVT2lM6KaJlNCsrdP/DyVH89YxkkAzKgtX0HAJhJ6VngovrcJhBiDIKUmRbBg59
 TFcispr6f+xw==
IronPort-SDR: eU0e3fnVpj0fmZD1AeZgpCuDK9ik87Y8q3k/d+ZfxYrbUZKdLn3JmnIBl9saLPu/FCNALdACcg
 UHgOK2zhCVgw==
Subject: Re: [PATCH] ASoC: Intel: Atom: use hardware counter to update hw_ptr
To:     "Lu, Brent" <brent.lu@intel.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc:     "Rojewski, Cezary" <cezary.rojewski@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jie Yang <yang.jie@linux.intel.com>,
        Takashi Iwai <tiwai@suse.com>,
        Liam Girdwood <liam.r.girdwood@linux.intel.com>,
        Mark Brown <broonie@kernel.org>
References: <1595779727-31404-1-git-send-email-brent.lu@intel.com>
 <7dec7fcd-0381-d279-4dac-77c27ea5f6fe@linux.intel.com>
 <DM6PR11MB3642BE84A5C91504D6AF4ECB97730@DM6PR11MB3642.namprd11.prod.outlook.com>
From:   Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Message-ID: <14fde5e9-a11a-077d-b533-1e6db4b7a262@linux.intel.com>
Date:   Tue, 28 Jul 2020 07:06:05 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <DM6PR11MB3642BE84A5C91504D6AF4ECB97730@DM6PR11MB3642.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 7/27/20 9:28 PM, Lu, Brent wrote:
>>
>> 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.

So if there are already quirks in atom machine drivers to change the 
period size, why is this patch necessary?

> 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.

I don't recall precisely what this hardware counter does. I vaguely 
recall it's tied to the 19.2MHz external timer which is also used to 
schedule the 1ms SBA mixer and the SSP IOs. And by comparing with the 
ring buffer pointer you can infer the delay inside the DSP. I think you 
are also making an assumption that all streams are tied to the output 
rate, but that's most likely a bad assumption. The hard-coded topology 
supported media, speech and compressed data and the consumption rate on 
the DMA side could be faster with some buffering happening in the DSP. 
It's not a passthrough DMA in all cases.

This is really legacy code that no one really fully understands nor 
plans on improving, it'd be a bad idea to change the pcm pointer reports 
now, 6 years after the initial code release and after all initial 
contributors moved on. It's what it is.

>> 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.

If you force info->pcm_delay to be zero, then runtime->delay is also zero:

see sst_soc_pointer():
	substream->runtime->delay = str_info->pcm_delay;

>>> -	info->pcm_delay = delay_frames;