The smoothing parameter _wlp (same as α in the previous formula) is defined as 200 / sampling rate. Note that the algorithm accumulates consecutive samples instead of building a smoothed vector. The pair (x2, y2) is what ends up to be used to determine the phase of the sine wave.
#Foobar2000 crossfeed dsp chain code
The classical formula for a discrete time smoothing filter is:īelow is the code where it is applied 2 times to real and imaginary parts: F->x1 += _wlp * (F->xa - F->x1 + 1e-20) Note-low pass filtering is not performed in the time domain, but rather in the frequency domain, thus the spectral composition of the signal remains the same. This is the corresponding part of the source code: c = cosf (a) Īfter obtaining real and imaginary parts of the frequency domain complex function value, the algorithm uses a simple low-pass filter two times in order to smooth out any abrupt changes in the signal's frequency domain form.
This is done for convenience, as using cosines would require shifting the calculated phase by π / 2 because the source signal is a sine wave. The algorithm also swaps "cos" and "sin" terms, and thus uses sines instead of cosines as the eigenvectors. The algorithm only needs the main harmonic of the signal, so it sets k to 1. In order to measure the phase of the sine wave that has returned back, the algorithm uses Discrete Fourier Transform formula expressed via Euler's formula in terms of sine and cosine functions: Thus, for the sampling rate of 48 kHz, the main sine has frequency of 48 / 16 = 3 kHz. For the main sine wave f equals to 4096 which emits the expression 2 * π * k * 1 / 16-that is, a period of 16 samples. The algorithm uses an expression 2 * π * k * f / 65536 for calculating the phase in radians for each sample of the sine waves it generates. The actual frequencies of those signals depend on the sampling rate. The delay estimator uses 13 sine signals. Nevertheless, let's ignore this shortcoming of the implementation and proceed to the delay estimation algorithm. a function that attempts to acquire a mutex lock). A correct modern solution would be to use atomic variables instead (but not a mutex, because the audio callback must call any function that could cause the thread to block, e.g.
This gives the compiler a lot of freedom in rearranging the order of operations, which can affect correctness of the results. What immediately occurred as strange to me is that the delay estimator class completely ignores the fact that it is being used in a multi-threaded setup-there are two threads that simultaneously read and write some of its fields, yet the latter are declared as ordinary variables. On the main thread the utility periodically checks and prints the current state of the delay estimator (mtdm): In the callback the delay estimator prepares and sends to output next audio buffer, and also receives a buffer of input data captured by the sound card. This callback is registered by means of jack_set_process_callback API call. Jack offers a processing callback which is called on a high priority (Linux "real time") dedicated thread, for low latency operation. This is how the estimator is hooked up in the program. The output and the input of the sound card need to be connected by means of a loopback cable: The utility is designed to measure round trip delay of sound cards, it calculates the delay from the phase of the returned signal. This utility is part of Linux JACK audio framework, its source code is available here. In this post I explain how jack_delay estimator works.
0 kommentar(er)
