0
$\begingroup$

Lets assume a pipeline X:

            in_buffer1 * window -> fft -> car_to_pol -> pol_to_car -> ifft -> out_buffer1
          /                                                                               \ 
in_signal                                                                                   out_buffer1 + out_buffer2  -> out_signal
          \                                                                               /
            in_buffer2 * window -> fft -> car_to_pol -> pol_to_car -> ifft -> out_buffer2

where in_buffer1 and in_buffer2 overlap in time by exactly 50% and the window is i.e. a hamming window with an offset matching the buffer.

the out_signal should be just a reconstructed in_signal with a delay depending of the buffers lengths with no frequency leaks.

However lets then consider a following pipeline Y for a single buffer with two sifnal sources and one result

in_signalA(n) ->  in_bufferA(n) * window -> fftA(n) -> car_to_polA(n)  ->     imgA(n)     ->   pol_to_car -> ifft -> out_buffer(n)
                                                                       \                   /
                                                                        realB(n) * realA(n)
                                                                       /
in_signalB(n) ->  in_bufferB(n) * window -> fftB(n) -> car_to_polB(n)

Then apply the same overlapping oerlapping as per the pipeline X where the n is the number of the pipeline, i.e. 0 - no offset, 1- 50% offset, This should produce a 'vocoder' effect.

However I do get cracks on the output signals which suggest there is a frequency leak I'm not compensating for. Any idea what I'm missing here?

Improve this question
$\endgroup$
6
  • $\begingroup$ Hi @michal-pawluk, and welcome to DSP.SE. It's hard to follow your algorithm description and understand your question, so maybe you can reformulate your question and add some code. Other than that: Have you tried simplifying your algorithm step by step, down to the basic WOLA framework, to determine when exactly the artifacts appear? In my opinion, it would be helpful to narrow down the source of the problem. Finally, element-wise multiplication of spectra may lead to time-domain aliasing problems since the corresponding impulse response does not fit within one buffer. $\endgroup$
    – applesoup
    Commented Jul 31, 2019 at 13:17
  • $\begingroup$ HI @applesoup I don't think it will be useful if I share the code... I'm using my own java implementation of fft and ifft which after being optimised are not readable anymore - no need for obfucsation :D But I'll follow your hint regarding the impulse response.. Unfortunately I'm quite new to the DSP field, prone to make silly mistakes... $\endgroup$
    – Michal Pawluk
    Commented Jul 31, 2019 at 19:10
  • $\begingroup$ I think the most important step towards the solution is to break down your problem into smaller pieces: Start with a very basic framework, omitting, e.g., signal B and the frequency-domain processing completely. Find the most reduced version of the framework which still works as expected and which does not produce any artifacts. Then, step by step, add more complexity until it breaks. Then you know exactly which step introduces the problem and you can work on precisely that problem. We here on DSP.SE are very happy to try and help then. $\endgroup$
    – applesoup
    Commented Jul 31, 2019 at 20:30
  • $\begingroup$ Hi @applesoup, I must admit it woul dbe hard for me to explain the poroblem in more detail before however thanks to your hint I have managed to resolve it. I was a bit worried the issue lies in my implementation of fft/ ifft even if it passed any unit test i could throw at it - the problem was actually with the multiplication in the frequency domain as you pointed out. $\endgroup$
    – Michal Pawluk
    Commented Jul 31, 2019 at 22:06
  • $\begingroup$ ... continuation... Applying i.e. hamming window to two 50% ovelapping source buffers reduces frequency leaks at the input however some windowing must be also applied on the output which will obviously not work well on two buffers... However increasing the number of buffers to four with 25% overlap did the trick. Thanks again for your suggestion :) $\endgroup$
    – Michal Pawluk
    Commented Jul 31, 2019 at 22:09

1 Answer 1

Reset to default
1
$\begingroup$

The solution turned to be the right number of overlapping input buffers. To get the source into fft and then back we need to apply windowing on the sources to reduce frequency leaks. Reconstructing such signal without any modification works just fine. However as @applesoup poined out certain operations in the frequency domain introduce their own discontinuities at the edge of output buffers so the output buffers must be windowed as well before combining into the output signal which in turn introduces inconsistency to the amplitude of the signal as in effect we need to apply same window twice. The solution to this problem is to double the number of buffers and change the overlap to 25% (of looking from the other side, to 75%) so each sample is reconstructed from 4 windowed output buffers which compensates the double windowing of each individual buffer.

Improve this answer
$\endgroup$
1
  • $\begingroup$ When applying windows both on input and output, you usually want to take the square root of a usual (amplitude complementary) window. That way, even 50% overlap should work, easily tested by just removing the ffts and checking if your OLA setup is transparent $\endgroup$
    – Knut Inge
    Commented Apr 18, 2022 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.