[PATCH] ASoC: qcom: q6asm-dai: Add SNDRV_PCM_INFO_BATCH flag

[Pierre-Louis Bossart]

On 3/30/20 1:15 PM, Lars-Peter Clausen wrote:
> On 3/30/20 7:52 PM, Stephan Gerhold wrote:
>> At the moment, playing audio with PulseAudio with the qdsp6 driver
>> results in distorted sound. It seems like its timer-based scheduling
>> does not work properly with qdsp6 since setting tsched=0 in
>> the PulseAudio configuration avoids the issue.
>>
>> Apparently this happens when the pointer() callback is not accurate
>> enough. There is a SNDRV_PCM_INFO_BATCH flag that can be used to stop
>> PulseAudio from using timer-based scheduling by default.
>>
>> According to 
>> https://www.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html:
>>
>>      The flag is being used in the sense explained in the previous audio
>>      meeting -- the data transfer granularity isn't fine enough but 
>> aligned
>>      to the period size (or less).
>>
>> q6asm-dai reports the position as multiple of
>>
>>      prtd->pcm_count = snd_pcm_lib_period_bytes(substream)
>>
>> so it indeed just a multiple of the period size.
>>
>> Therefore adding the flag here seems appropriate and makes audio
>> work out of the box.
>>
>> Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver")
>> Cc: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
>> Signed-off-by: Stephan Gerhold <stephan at gerhold.net>
>> ---
>> I'm still quite confused about the true meaning of SNDRV_PCM_INFO_BATCH,
>> so please correct me if I'm wrong :)
> 
> The meaning might have changed over the years, but the way it is used 
> right now is that it means that the position pointer has limited 
> granularity. With 'limited' being a bit fuzzy, but typically means that 
> the granularity is worse than a few samples.
> 
> This driver definitely falls into the limited category as the 
> granularity seems to be period size.

Agree, we added this INFO_BATCH flag for SOF Broadwell and Baytrail 
platforms as well for the same reason of large granularity.