[Sound-open-firmware] [PATCH] topology: SRC: Use 4ms for topology scheduling and increase buffers

[Pierre-Louis Bossart]

On 9/8/17 1:37 AM, Seppo Ingalsuo wrote:
> 
> 
> On 07.09.2017 19:17, Pierre-Louis Bossart wrote:
>> On 9/7/17 8:28 AM, Liam Girdwood wrote:
>>> SRC should be scheduled on at least 4ms tick. Increase buffers to
>>> deal with 2 times output rate.
>>
>> It's ok to increase buffer sizes to account for the varying sizes 
>> between input/output, but why would the scheduling be impacted? 4ms is 
>> a very large tick, this makes no sense to me.
> 
> Yes, you are right that the scheduling for this pipeline could be kept 2 
> ms while buffer size would be increased to fit the SRC output block 
> size. For 44.1 kHz to 48 kHz conversion the SRC produces 160 samples 
> blocks at 48 kHz side every ~3.3ms. This change can be restored after 
> the configuration errors check code in SRC params() is improved. I will 
> work with that.

temporary fixes are just fine. I was just trying to figure out if there 
is a minimum block or scheduling assumption here. I probably need more 
coffee this morning but does the implementation wait for 147 input 
samples to be available before being able to generate an output so as to 
have predictable scheduling? if we tolerated more variability on the 
number of cycles, could we not reduce this block size?