Delay a signal in time vs in frequency

I have a signal h that I want to delay for a time t.

I know that I could use two possible approaches:

1. $$h_{\text{delay}}[k] = \delta[k-\tau]\star h[k]$$
2. $$h_{\text{delay}}[k] = \text{IFFT}\left(\lvert H(\omega)\rvert e^{j\phi(\omega)}\cdot e^{-j\omega \tau}\right)$$

Which theoretically should be completely equivalent (as far as I know).

From the performance and precision point of view, which of the 2 is better? Is there any trade-off in numerical precision or speed?

• you can answer both the questions yourself, it seems! So, what's the reason you're asking this? Feb 15 '21 at 16:33
• I am working on my MSc thesis on 3D audio in embedded systems. I noticed that theoretically the FTT-IFFT should return the exact identical signal, in pratice some noise/approximation errors can happen, expecially if working with limited resources where each bit "counts". I also know that convolution via FFT is faster than the time one, however I also read some papers where they reported that this is true to a certain extent, for small convolution the time spent in doing FFT-IFFT isn't worth the gain in the convolution speed. Feb 15 '21 at 16:44
• Anyway, I saw that you edited the formulas, now the time delay is included in the exponential, is it correct? Feb 15 '21 at 16:45
• but, wait: In an implementation, you'd never implement an integer delay as the convolution of your input with a dirac impulse?! Feb 15 '21 at 16:45
• ... because it's really just a very complicated and CPU intense way of saying h_delayed[k]=h[k-tau]. Feb 15 '21 at 16:59

Is there any trade-off in numerical precision or speed?

Yes. For delays that are integer multiples of the sampling period method 1 is far superior: it's computationally efficient, it's bit-exact, it's easy to implement and it's almost fool proof.

Method 2 is computationally expensive, you need to pick an FFT length (which is not trivial) it's subject to numerical noise and it incurs significant latency. It implements a circular shift, not just a delay and so you need to manage overlap, frame boundaries, etc which is easy to get wrong.

Non-integer (or fractional) delays are completely different can of worms and quite complicated. Suggested reading: Splitting the unit delay

• Using method 2 adds a significant processing delay (you need to accumulate N points, to compute a N-point FFT) which could be a killer for real-time implementation.
– Ben
Feb 15 '21 at 17:09
• That's what I meant by "latency" Feb 15 '21 at 18:17
• My mistake, sorry.
– Ben
Feb 15 '21 at 18:22
• “Non-integer (or fractional) delays are completely different can of worms and quite complicated” – they can be, depending on the requirements – but in practice a suitable interpolation will generally still be much easier than anything involving FFT. A Lanczos can be made practically indistinguishable from a sinc, and in many applications simple cubic or even linear interpolation is also sufficient. Feb 16 '21 at 16:03

At the risk of blowing my own trumpet and that of my co-author, Bob Williamson, there is also this paper which shows the equivalence of three techniques referred to in the FIR link in Ben's answer and also referred to in the paper linked to from Hilmar's answer.

The two results that are of particular interest are Proposition's 2 and 3 of the paper, screenshots included below.  As Hilmar pointed out, for delays that are integer multiples of the sampling period, method 1 is far superior.

Also, Method 1 is more suitable for real-time operations as you don't need to buffer the data to perform the FFT.

For delays that are non-integer multiples of the sampling period you can adapt method 1 by using an FIR or IIR filter using Lagrange coefficients.