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

[Seppo Ingalsuo]

On 08.09.2017 21:29, Pierre-Louis Bossart wrote:
>
>
> 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?

There are some easy fractional conversions like 32 <-> 48 (3/2) and 48 
<-> 64 kHz (3/4). For simplest 1/N or N/1 conversion there's no framing 
delay for the side that produces or consumes single samples.



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