rePhase, a loudspeaker phase linearization, EQ and FIR filtering tool - Page 27 - diyAudio
Go Back   Home > Forums > Loudspeakers > Multi-Way

Multi-Way Conventional loudspeakers with crossovers

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 5th January 2013, 06:06 PM   #261
diyAudio Member
 
Join Date: Jan 2008
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.
  Reply With Quote
Old 5th January 2013, 06:11 PM   #262
diyAudio Member
 
Join Date: Jan 2006
Location: grenoble
VSTconvolver use FFTW 3.1.2 library.

from FFTW.org

Quote:
...
...
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...).
  Reply With Quote
Old 5th January 2013, 06:18 PM   #263
pos is offline pos  Europe
diyAudio Member
 
pos's Avatar
 
Join Date: Feb 2008
Location: Paris
This is fast in term of CPU time, not elapsed time: FFT convolution requires additional buffering, this cannot be avoided.
  Reply With Quote
Old 5th January 2013, 06:18 PM   #264
diyAudio Member
 
Join Date: Feb 2009
Location: UK
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.
  Reply With Quote
Old 5th January 2013, 07:39 PM   #265
diyAudio Member
 
Join Date: Jan 2006
Location: grenoble
Quote:
Originally Posted by pos View Post
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.
  Reply With Quote
Old 5th January 2013, 08:07 PM   #266
pos is offline pos  Europe
diyAudio Member
 
pos's Avatar
 
Join Date: Feb 2008
Location: Paris
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).

Last edited by pos; 5th January 2013 at 08:10 PM.
  Reply With Quote
Old 5th January 2013, 08:35 PM   #267
diyAudio Member
 
Join Date: Feb 2009
Location: UK
Quote:
Originally Posted by more10 View Post
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.
  Reply With Quote
Old 5th January 2013, 08:43 PM   #268
diyAudio Member
 
Join Date: Feb 2009
Location: UK
Quote:
Originally Posted by pos View Post
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.

Last edited by CopperTop; 5th January 2013 at 08:47 PM.
  Reply With Quote
Old 5th January 2013, 09:08 PM   #269
pos is offline pos  Europe
diyAudio Member
 
pos's Avatar
 
Join Date: Feb 2008
Location: Paris
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?

Last edited by pos; 5th January 2013 at 09:11 PM.
  Reply With Quote
Old 5th January 2013, 10:01 PM   #270
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by pos View Post
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.

Quote:
Originally Posted by CopperTop View Post
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.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FIR linear phase plugin for MiniDSP? diyjb01 miniDSP 13 7th February 2014 02:24 AM
FIR filter design tool for Loudspeaker magnitude equalization ttmusic Software Tools 3 24th May 2013 09:30 PM
FIR Filtering experiences Olombo PC Based 8 10th February 2013 04:45 PM
AVX based FIR VST, crossover / EQ / DRC and delay KOON3876 PC Based 97 26th November 2012 08:18 AM
Phase EQ using FIR filters Grasso Multi-Way 2 2nd July 2003 11:37 PM


New To Site? Need Help?

All times are GMT. The time now is 04:03 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2