Return delay values for time domain functions

[hagenw]

We have started to work on this by returning the delay from wfs_preequalization() as well as from driving_function_imp_wfs(), see #62.

The same behavior should be added to delayline(). As this function is updated in general at the moment (see #50), this feature is postponed after finishing #50.

[hagenw]

@fietew: #50 is now merged, so we should have a look at this.

What was the basic idea for this? The delayline() is supposed to delay the signal by the given delay and should not introduce a delay offset?

[fietew]

If I remember correctly, this was about the correct absolute time for synthesizing sound fields, meaning that t=0 is really the point in time where the sound sources starts to radiate. Almost all current fractional delay filter introduces pre-delay. The idea was to provide the added delay via an additional output parameter, like e.g. in https://github.com/sfstoolbox/sfs/blob/master/SFS_time_domain/wfs_preequalization.m and compensate it during the sound field plot. I think, that the latter is been already implemented in #62.

This should be solved by adding a few lines of codes after
https://github.com/sfstoolbox/sfs/blob/master/SFS_time_domain/driving_function_imp_wfs.m#L148
and add a delay_offset out parameter to the delayline. What do you think?

[hagenw]

That sounds more like a bug in the delayline() function. I would suspect that delayline() adds only the specified delay to the signal and no additional delay coming from signal processing. Should this additional signal processing delay then directly compensated for inside delayline()?

[fietew]

How should this be possible? If an fractional delay filter has an non-causal impulse response, e.g. the ideal fractional delay filter is a sinc function, then you have to add pre-delay to implement it. Hence, the peak of the fractional delay filter's impulse response h[k] cannot be at k=0 (or k=1 in MATLAB).

[fietew]

Implemented: https://github.com/sfstoolbox/sfs/tree/return_delay

[hagenw]

I'm sure we could still compensate for at least the integer part of the delay offset at the end of delayline(), but I agree that this should normally not needed as you normally not combining to delay lines using different filters, and if so you could also compensate for the delay yourself.

I created a pull request for your changes: #82

[hagenw]

OK, is integrated now.