Partitioned convolution discussion

[LionIT]

So the signal went through the same Blackhole device twice?

Not exactly.
1) REW sends sweep to BlackHole output ch. 1
2) Reaper acquires BlackHole input ch. 1 (looped back from REW)
3) Reaper is configured to reroute audio to BlackHole output ch. 2
4) REW acquires BlackHole input ch. 2 (looped back from Reaper)

There is no overlap if that is your doubt.

It is only in this precise configuration that the signal degrades.
If I play the REW's sweep with another app, like Apple Music or Audacity or any other player, and use the double loopback config as said before, everything works normally: THD+N below -140dbfs.

It's pretty weird and I think it depends on how REW handles drivers or how Core Audio works.

But that's not the only anomaly with REW: I have noticed that in direct loopback measurements via Blackhole (ch1 out to ch1 in), if I start signal generation first compared to the acquisition of RTA, it is not possible to use a rectangular window, there is a lot of noisefloor fluctuation. As if there was a clock problem. But if I do the opposite, first I start RTA and then the generator, all perfect.
I suspect that the problem with the measurement via sweep is correlated and depends on the opening of the devices.

 

[mcdn]

This is the most important part. Unless there are bugs, the result is the same no matter what, except for numerical noise which will be different for different implementations anyway.



Here, a & b would be easily detected bugs. The first half of c is mostly nonsense, but the second half about rounding is true. However already with 32-bit floats any correct implementation will get a noise level in the vicinity of -150 dB (and -300 dB for 64-bit) so not an issue.

Points 3-5 are nonsense, because point 1

@HenrikEnquist I've just read Frank Wefers' paper (https://publications.rwth-aachen.de/record/466561/files/466561.pdf?subformat=pdfa&version=1) and if I understand it correctly there will be a slight difference in output for the first N output samples of a length-N FIR filter between an NUPC and a delay line implementation. In practice this is not consequential as most audio streams are continuous so it only affects a very short time during initial startup, but it is a difference in output. Have I got this right?

 

[bmc0]

if I understand it correctly there will be a slight difference in output for the first N output samples of a length-N FIR filter between an NUPC and a delay line implementation.

No, the output samples are identical irrespective of partitioning scheme (or lack thereof), save for cumulative rounding error.

 

[mcdn]

No, the output samples are identical irrespective of partitioning scheme (or lack thereof), save for cumulative rounding error.

A delay line FIR of length N gives its first output after N samples, after convolving the entire filter against the first N samples of the input.

A partitioned FIR with the first partition of length e.g. N/8 gives its first output after N/8 samples before it’s even seen the remaining 7N/8 samples.

How can the first N outputs be the same? I’m not asking about the steady state, but about the startup state.

 

[bmc0]

A delay line FIR of length N gives its first output after N samples, after convolving the entire filter against the first N samples of the input.

For clarity: by "delay line FIR", do you mean direct-form convolution? If so, then you get an output from the very first sample. Consider the following filter structure:

(from Wikipedia)

It can be seen that there is a non-delayed path from the input, x[n], to the output, y[n]. Real time convolution requires that the filter be causal, meaning that a given output depends only on previous inputs. So, y[n] can be computed from x[n - i], where 0 ≤ i ≤ N and N is the filter order (i.e. number of taps minus one). The sample values for negative indices are defined as equal to zero. Alternatively, one could think of the initial state of the delay line as being all zeros.

 

[mcdn]

is an emoji I have use often! Thank you @bmc0, thinking of the delay line as pre-filled with zeroes makes it all clear. This is the sort of patient explanation to dummies like me I love about ASR.