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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware