Variable Delay Line in Software

Let A denote an array of length $N$ . Then we can implement an $M$ -sample variable delay line in the C programming language as shown in Fig.1. We require, of course, $M\leq N$ .

Figure 1: The $M$ -sample variable delay line using separate read- and write-pointers.

 

   static double A[N];
   static double *rptr = A; // read ptr
   static double *wptr = A; // write ptr

   double setdelay(int M) {
       rptr = wptr - M;
       while (rptr < A) { rptr += N }
   }

   double delayline(double x)
   {
     double y;
     A[wptr++] = x; 
 y = A[rptr++];
     if ((wptr-A) >= N) { wptr -= N }
     if ((rptr-A) >= N) { rptr -= N }
     return y;
   }

The Synthesis Tool Kit, Version 4 (STK-4) [5] contains the C++ class ``Delay'' which implements this type of variable (but non-interpolating) delay line. There are additional subclasses which provide interpolating reads by various methods. In particular, the class DelayL implements continuously variable delay lengths using linear interpolation. The code listing in Fig.1 can be modified to use linear interpolation by replacing the line

  y = A[rptr++];

with¹

  long rpi = (long)floor(rptr);
  double a = rptr - (double)rpi;
  y = a * A[rpi+1] + (1-a) * A[rpi];
  rptr += 1;

To implement a continuously varying delay, we add a ``delay growth parameter'' g to the delayline function in Fig.1, and change the line

  rptr += 1; // pointer update

above to

  rptr += 1 - g; // pointer update

When g is 0, we have a fixed delay line, corresponding to ${\dot D_t}=0$ in Eq.$\,$ (5). When $\texttt{g}>0$ , the delay grows $\texttt{g}$ samples per sample, which we may also interpret as seconds per second, i.e., ${\dot D_t}=\texttt{g}$ . By Eq.$\,$ (6), we see that we need

$$\texttt{g} = -\frac{v_{ls}}{c}$$

to simulate a listener traveling toward the source at speed $v_{ls}$ .

Note that when the read- and write-pointers are driven directly from a model of physical propagation-path geometry, they are always separated by predictable minimum and maximum delay intervals. This implies it is unnecessary to worry about the read-pointer passing the write-pointers or vice versa. In generic frequency shifters [10], or in a Doppler simulator not driven by a changing geometry, a pointer cross-fade scheme may be necessary when the read- and write-pointers get too close to each other.