Good point. IIR filters do differ across processors.....witness the list of about 30 manufactures REW has for selection, when using it's auto-EQ capbility.
Here's another Eclipse link on filter implementation differences in certain proamps, and the software to translate those differences from one platform to another. https://eclipseaudio.com/iir-brand-differences/
And sure, it clearly takes knowing the exact math used to make such translations.
It's worth noting I think, that whatever modeling/simulation/even math itself that one is using to predict the IIR filters needed to correct raw measurements of drivers/speakers, can have the same potential translation issues when put into a processor.
Maybe using only biquads can solve that...if all computing parameters are the same? (Bit depth, fixed vs floating etc)
Dunno, Out of my element here.. Anyone?
I don't use auto 'spit out' 🙂 for IIR, partly due to the translation problem being discussed.
If post #55, I said how I determine IIRs to be used for driver corrections...
I don't design them...I just implement them.
Turn on real-time transfer function measurement. Gonna do some simple "knob twisting".
This technique precludes translation issues.
Also worth noting in this post, FIR does not have the translation issues between processors, that IIR has.
Gives exact same results on any processor than can handle the FIR file's tap count and sample rate.
Oh, my goodness ... there are so many implementation issues here.
Fixed-point or floating-point?
If fixed-point, how many bits? Is extended precision available for intermediate operations? How many bits of extended precision? Do I scale to prevent any possiblity of numerical overflow (or underflow), or just to prevent it most of the time? If "most of the time", then define "most of the time". Saturate an overflow, or let it wrap? (Letting it wrap in intermediate results can be advantageous.) True fixed-point or block floating-point? What technique to use, to prevent limit cycles in IIR filters?
If floating-point, single-precision or double-precision? Or perhaps single-precision most of the time, but cast to double-precision for critical operations? Can I tolerate the potential speed penalty of double-precision?
In general:
Is a floating-point coprocessor available? If not, how to approximate transcendental functions; algorithm, table look-up, combination of the two? How accurate is the approximation? The ultimate accuracy achieved in some functions is dependent upon the order in which the operations are performed; have you taken that into account? You don't have enough processor power or memory; what compromises are you going to make to get it to fit?
Not necessarily true, particularly in fixed-point.
Implementing in floating-point is such a luxury.
Thx for that detailed reply. Makes me even more scared of IIR, lol.
I think the things you mention are for an excellent processor engineer like yourself to work out and provide, either for the commercial market of because they have a hoppy in DIY electronics.
But I can't see how they have any relevance for DIY speaker builders, other than knowing what specs to look for in choosing a processor.(or building one for their own use)
Does any processor that isn't considered legacy still use fixed-point?
I thought fixed-point is such a bygone era., that floating-point is no longer a luxury. No?
I think the things you mention are for an excellent processor engineer like yourself to work out and provide, either for the commercial market of because they have a hoppy in DIY electronics.
But I can't see how they have any relevance for DIY speaker builders, other than knowing what specs to look for in choosing a processor.(or building one for their own use)
Does any processor that isn't considered legacy still use fixed-point?
I thought fixed-point is such a bygone era., that floating-point is no longer a luxury. No?
Understood. I just wanted to point out that different environments, and different programmers, can easily lead to different implementations with different performance. (The performance differences should be very small, though, if done right.)
We can thank the cell phone market for low-cost floating-point processors with extraordinary performance! They made digital signal processing so much easier to implement.
Fixed-point is still available for small, low-cost embedded applications.
The phase change of analog output filters after DAC is not the same from model to model. Even the digital filter can be different.
Not a problem if not summing operations are done but if summing, then you have to know the phase
Not a problem if not summing operations are done but if summing, then you have to know the phase
Can a similar FIR crossover effect be seen using real measurements? If so, how?
a phase linear xover does not cause pre echos (at least not on axis where the summing is perfect). the pre echo comes at the band limits (low and high frequency corners)
Perfect summing of two speaker elements should be seen as a spesial case that the user dont experience often during the use of the speaker and dont say much obout the sound quality
Pre and post echo is best seen in time domainn with a delta peak as input. Just like post echo in a room
Summing of filter outputs with a time delay is easy to simulate and measure with a signal prosessor (adau, camilla++)
An really important feature of the phase linear or LR filters is that phase is 0 or 360 degrees apart on all freq where summing of the elements adds to the result. But when that is no longer the case the speaker building art begins
Is that correct?
I know widowing effects the generated FIR file, the actual coefficients in the FIR file. (As I routinely experiment with different windows generating FIR files)
My understanding is that once a FIR file is generated, no further processing beyond CPU multiplication and addition occurs.
Which if correct, means FIR files have the same digital output, same transfer function, no matter what processor is used.
Whether or not processors have differing DAC conversions seems immaterial to the question of FIR output remaining constant across processors.
Such a pulse requires an infinite bandwidth from the DSP, i.e. frequencies from 0Hz to infinity Hertz. As I understand it, if the frequency of a signal transmission line is frequency limited, then the pulse passed through such a line must have waves (ringing), then, to fulfill the linear phase condition, the pulse must be symmetrical, i.e. there must be waves before and after the impulse. As I understand it, the symmetry of the pulse is a condition for ensuring a linear phase, and the waves before and after the pulse are a consequence of the limitation on the transmission frequency. In other words, if I work in the DSP passband, then I should not be bothered by these waves before and after the pulse, or, more simply put, there should be no ringing on a signal that is in the DSP passband.
As a result, as I understand it, ringing before and after the pulse does not give me an answer - whether there will be an additional echo in the signal from this ringing if the signal is in the passband of the filter.
And now I’m very interested in seeing ringing in the DSP passband, i.e. roughly speaking, I want to see ringing on a 300Hz sine wave with a 300Hz FIR crossover.
As I understand it, the pre-echo at the crossover frequency is far from the echo that everyone thinks about when they look at the IR FIR view.
At the crossover frequency we have a certain “balancing of the bands” in amplitude and phase, so that with the sum of the bands we get a total signal with a linear phase of the required amplitude. This is a certain effect of the transient response of the filter, in which the total signal will be of a given frequency and amplitude with a given phase.
@uriy-ch Transients occur in music. And is best viewed in time domain.
Summing of sharp filters is no problem as long as it is no ucontrolled phase differense. Else MP3 would not function.
Summing two speaker elements is another story. Thats why people messure polar plots, DI and power transfer function
We could also have used subtractive filters to have a perfect output if phasedifferense is always n x 360
Summing of sharp filters is no problem as long as it is no ucontrolled phase differense. Else MP3 would not function.
Summing two speaker elements is another story. Thats why people messure polar plots, DI and power transfer function
We could also have used subtractive filters to have a perfect output if phasedifferense is always n x 360