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?