Calculate transport delay

[mildsunrise]

It'd be very helpful to know the transport delay that a given converter at a given ratio exhibits. I'd suggest a function like:

/*
**  Calculate the transport delay (number of samples that are buffered
**  on average) that a given converter exhibits, when resampling at the 
**  specified SRC ratio.
**  Returns the transport delay, measured in output samples.
*/
double src_get_delay (int converter_type, double src_ratio) ;

For the linear and ZOH converters the calculation is very easy (something along 1 + 1/src_ratio if I recall correctly), but I'm not able to come up with an expression for the sinc converters (which are perhaps the most interesting cases, where the transport delay is significant).

[polaris]

I am very interested in this function too.

[arlofaria]

I think such a function would be helpful for anyone trying to speed up SRC by parallelizing its computation over multiple threads. You could split the input to apply SRC independently on each segment, but then it'd be good to know how much overlap is needed between adjacent segments so that you can stitch it together correctly -- ideally to get bitwise identical results compared to single-threaded processing. FWIW: my goal would be to make SRC as fast as VAD, which can be thousands of times faster than real-time -- but it operates internally on 8kHz audio.

[evpobr]

Hi @arlofaria.

I like this idea, but we still have no developer to implement this. Maybe you can help us?

[arlofaria]

Hi @evpobr, and thanks for contributing this terrific software to the open-source community!

I've only used SRC as a black box before, but took a quick glance into the code right now -- proceeding past the ominous comment -- and I suppose that the delay of a sinc filter, in terms of input samples, would be something like:

int src_get_sinc_input_delay(SINC_FILTER *filter, double src_ratio) {
  return filter->coeff_half_len / (filter->index_inc * (src_ratio < 1.0 ? src_ratio : 1.0));
}

Does that seem correct?

[evpobr]

thanks for contributing this terrific software to the open-source community!

Thank you :smile:. To be precise, the author is @erikd, and we are helping to support this project as much as we can.

@SoapGentoo , can you take a look?

[SoapGentoo]

my knowledge of resampling algorithms is very rudimentary, @arlofaria could you send in a PR maybe?

[arlofaria]

Hi @SoapGentoo, sorry I didn't notice your pull request request!

Is there nobody else available who has a better understanding of these internals?

To clarify: this src_get_since_input_delay function shouldn't be necessary if the consumer is otherwise willing to break the abstraction boundary and peek into src->private_data (as @scjurgen demonstrates in #175).