rePhase, loudspeaker phase linearization, EQ and FIR filtering tool

[Barleywater]

Latency is directly dependent on tap count, and in case of partitioned convolution partition count. Apparent latency with minimum phase filters is good, but once time reversal is invoked for phase correction this advantage disappears.

If direct convolution were faster, PC setups would use it.

[thierry38efd]

VSTconvolver use FFTW 3.1.2 library.

from FFTW.org

...
...
The FFTW package was developed at MIT by Matteo Frigo and Steven G. Johnson.

Our benchmarks, performed on on a variety of platforms, show that FFTW's performance is typically superior to that of other publicly available FFT software, and is even competitive with vendor-tuned codes. In contrast to vendor-tuned codes, however, FFTW's performance is portable: the same program will perform well on most architectures without modification. Hence the name, "FFTW," which stands for the somewhat whimsical title of "Fastest Fourier Transform in the West."
...
...
Awards

FFTW received the 1999 J. H. Wilkinson Prize for Numerical Software, which is awarded every four years to the software that "best addresses all phases of the preparation of high quality numerical software." Wilkinson was a seminal figure in modern numerical analysis as well as a key proponent of the notion of reusable, common libraries for scientific computing, and we are especially honored to receive this award in his memory.

i trust this way to convolve.(also in medical,military,imaging...).

[pos]

This is fast in term of CPU time, not elapsed time: FFT convolution requires additional buffering, this cannot be avoided.

[CopperTop]

I would only find latency an issue if I was using the system with video, or in a recording studio situation. For strictly purist audio hi fi I'm happy to add up to a second of latency if that's what it takes.

Re destroying the speakers if the system goes wrong, I have my amps set to a level (using pots) that is a bit too high for a typical loud piece of music when the software volume is at max, and no more. The tweeter has a series cap to protect it. I have a 'boost' button in my software for quiet stuff (classical often doesn't reach full scale I find) and a latching clipping indicator so I'll know next time not to use it if the piece gets too loud. I did, at one point, have a software meltdown where a coding error caused the FIR filters to be calculated way too loud when a certain combination of settings was selected. The resulting cacophany
was unbelievable, but no damage done.

[thierry38efd]

Originally Posted by pos

Thierry, I am talking about real elapsed time (delay), not CPU time.
In direct convolution with a hardware solution like the openDRC and a DAC, you can expect only a few ms of delay in addition to the "normal" delay implied by the impulse (depending on the position of the peak within the impulse).
A PC would already add some buffering delay for the soundcard, and some more if FFT is used...

I have missed this message.
ok.I misundestood you.

is it very important if no feedback is used,only delayed video to sync with sound.
about miniSharc or miniDSP,openDRC,the message you've posted tells that FFT convolution will be implemented.
once coding done,they will probably change all direct conv. to FFT.

[pos]

Not sure they will (or can, because of memory constraints) implement FFT convolution.
If they do, I hope they will let the final choice to the user, in the plugin configuration.
With downsampling I don't see the need for such "complication" in an active filtering situation.

Time will tell, but I think hardware convolution will soon become commonplace, and optimization technics like FFT convolution or downsampling will probably rapidly become obsolete, exactly like palleted color modes in PC graphical cards...
Convolution will soon become the de facto standard for filtering and EQ, with the cursor set anywhere between fully linear phase and minimum phase to accommodate any situation (ie allowed delay).

[CopperTop]

Originally Posted by more10

I2S in all communication with either sources or targets.

What sort of source is that? As I understood it, I2S is for linking together ICs on the one PCB, or in the same box at least.

[CopperTop]

Originally Posted by pos

Time will tell, but I think hardware convolution will soon become commonplace, and optimization technics like FFT convolution or downsampling will probably rapidly become obsolete, exactly like palleted color modes in PC graphical cards...

I'm not so sure. I have a feeling that the future will be very energy-conscious compared to now, whether that's literally because of a shortage of fuel, or because everything will be judged on how much it drains the batteries of portable devices. Direct convolution is hideously expensive in terms of energy and yet for most purposes is identical in its result to the FFT-ed version, whereas palleted colour modes were not identical to true RGB.

[pos]

The entier openDRC (miniSHARC + IO card + infrared compatible volume control and selector) is powered by a 5V 600mA powersupply. So it shall not consume more than 2.5W!
And future evolutions of such cards are likely to consume even less power for even more capabilities.
I don't think you could build a PC with that kind of power consumption

In fact it could already be possible without problem to do a complete 8-way linear-phase crossover with only one miniSHARC and with direct convolution if they implemented taps distribution and downsampling.
(Look at what Four Audio manage to do with the limited power of the HD2)

So why bother with a PC? Having a unique media center is not what I would like to have.
I want to be able to connect any device to my speakers, even TV (which means 0 delay *should* be an option, with only minimal-phase correction in this case of course), and let the whole thing on all day long if I want, or turn it off and on whenever I want without having to wait XX seconds to get it up and running.

0 delay is impossible with FFT convolution, even with a minimal phase impulse, so if it can be avoided let it be!
And it can, today already, with energy-conscious, compact and affordable hardware. What not to like?

[twest820]

Originally Posted by pos

You should add a short FIR to do a brickwall LP at Nyquist nonetheless, to avoid any problem.

Which problems, specifically? I'm familiar with the motivation for apodizing filters but my experience is subjective audio quality tends to be dominated by the impulse ringing introduced by the filter. Since the Fourier relation mandates an abrupt transition in the frequency domain is a slow one in the time domain brickwall is often a worst case choice in this regard---it's my experience a more even tradeoff of frequency and time domain behavior sounds better. Upsampling from 44.1 mitigates the issue but requires caution as most sample rate conversion defaults to brickwall antialiasing (miniDSP is unlikely to document their implementation on the miniSHARC---someone'll have to get one and measure it---but Analog's ASRC implementations are all brickwall so I'd expect miniDSP's to also be brickwal), as do the majority of DACs. So adding a third brickwall in one's own filtering is an interesting choice.

Originally Posted by CopperTop

How are you going to link your audio source to the DSP card? Can you avoid opening a whole new can of worms, worrying about real or imaginary jitter, resampling etc.?

Probably the simplest option is asynchronous audio, where whatever device that has the master clock tells the data source how fast to send data. This is used in the ASIO and USB Audio Device Class 2.0 specifications, for example, and avoids the jitter and lock concerns of PLLs or the additive impulse ringing of ASRC. If you do a search you'll find oceans of discussion about ASRC and PLL methods here on DIYA and elsewhere. But I guess my main remark would be that DIYers are fond of elaborate solutions to possible problems and not necessarily so focused on determining what is and is not audible in ABX testing (and finding ways to address what is audible). My personal ABX results have favored PLLs over ASRC (though if one does the ASRC right it can be almost as good) in most cases (also, TI makes several jitter cleaners that one can apply to PLL recovered clocks if one's really worried about jitter---I don't know of any ABX results on this but the jitter cleaners outperform the phase noise of what are widely considered reference quality crystals by an order of magnitude or more). ESS's approach of combining the ASRC and DAC antialiasing is an elegant one, particularly as their slow rolloff is the slowest linear phase roll in the industry that I know of, and can be attractive if one wants simple clock mangement (hence my feature asks earlier in this thead to enable rePhase to synthesize antialiasing filters for ESS DACs). However, choosing a PLL with good jitter rejection and cleanly routing its recovered clock to a DAC is really not that hard.