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

[Seppo Ingalsuo]

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.


> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>