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

[Pierre-Louis Bossart]

On 09/08/2017 01:01 PM, Seppo Ingalsuo wrote:
>
> On 08.09.2017 17:48, Pierre-Louis Bossart wrote:
>> 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?
>
> The current SRC implementation is such that it executes the whole 
> polyphase filter matrix in a single run when sufficient amount of data 
> is available. That simplifies filter core and improves computation 
> performance with avoiding of control code but it increases latency.
>
> That may need be revisited (it's not that complicated but the jitter 
> in number of samples in/out happens - it shouldn't be an issue for 
> SOF) since for 11025 Hz to 48 kHz the used fraction is 640/147. It 
> would cause much longer buffers need and delay.
>
> In 48 kHz family fractional conversions with easier fractions the min. 
> buffer needs are much shorter. It might be useful to make two variants 
> of filters core.

For the 48khz and integer resampling, why do we even have a min buffer? 
Apart from the downsampling case where you need N samples before being 
able to generate a new one, for upsampling you could work at the sample 
level. If you push the input into a delay line and work from there you 
are good to go. what am I missing?