I just got a pair of M2's and am trying to figure out source and amp. My original plan was to get a couple of 500HDs - I dont need that much power, but I like that it has AES input. But, its only 96k. If I instead did the crossover in my PC source and used a multichannel DAC then I could use higher rates - and other amps.
After reading a lot of discussion on using DSP devices and digital crossovers, my questions are:
1. Can I port those settings to JRiver or similar and use my PC? It seems like it can handle lots of fir taps
3. How does it sound vs.the filters in iTech/BSS? I could not find a comparison. (doesn't help that "M2" and "fir" are too short for the search function here)
Thanks, John
Hi John
The google doc in my signature has rephase presets embedded in it that you can use to generate FIR filters for Jriver.
It embeds delays and conservative (< 0dB everywhere unlike the original BSS/Crown preset) gain settings.
As you have many taps available I would suggest you set the optimization setting to 'none' in rephase.
This is a question for POS. The DSP solution you worked out using the OpenDRC DI units (much appreciated BTW) uses one DI unit per speaker operating in mono mode - one for the left speaker and one for the right. Can you see any reason why you couldn't set things up so that both units operated in stereo mode but with one handling the CD crossover duties the other handling the woofer crossover?
Hi iansr
Yes it should work just as well, I just found that one unit per speaker was the easiest way to do it.
I see
Make sure you measure both DACs to make sure their delays are identical, as they depends on the antialiasing filter used (minimum-phase, slow or fast linear-phase, etc.)
In this scenario you could also install the miniSHARC 96k firmware and plugin on the HF openDRC, to get 96k operation, and probably enough taps for the task at hand (would have to check this, but I cannot remember how many taps you get in this situation...).
You would again have to measure and adjust delays for openDRC+DACS, as 96kHz operation typically have half the delay of 48kHz operation when it comes to antialiasing filters (DAC, ASRC, etc.)
Although the DACs will be different they are both being designed by John Westlake and they will be clock locked with one being the master and the other the slave.
interesting idea about the 96k firmware. Showing my ignorance here but why wouldn't you also use it on the woofer channels?
At 96kHz you typically get 1/4 of the FIR correction capabilities.
LF corrections typically require more than HF ones.
2048 taps at 96kHz is not enough to properly implement the LF correction needed for the M2:
(blue=target, red=result ; plain=magnitude, dashed=phase)
It is enough fo the HF part though:
@pos
the M2s are probably amongst the most accurate speakers in the world and they deserve the best associated gear. I use the miniDSP OPenDRC DI units for the crossovers and I strongly suspect that they are a weak link, relatively speaking. (In particular, I suspect the ASRC is degrading the sound quality.) I don't imagine for a moment that the official Crown DSP solution would be much different. I'd really like to use a SOTA DSP engine and so this caught my eye:
http://www.analog-precision.com/UPXO.html
As someone who knows a lot more about this stuff than I do, I'd welcome your thoughts.
Hi iansr,
The openDRC-DI is not a bad unit at all.
The ASRC is quite good (-128dB "noise"), and if you use a DAC that is immune to jitter (like a sabre DAC) you should be good to go with the digital output.
With a 48kHz ASRC per unit you might get as much as 1/48 msec delay difference between two units, which is equivalent to about 7 mm of travel time, although half of that would be more typical.
Convolution itself is direct and operated on 32 bits floats, and should be as good as it gets.
The UPXO certainly looks like a state of the art unit, with very well thought clocking, DAC and analog sections, including a centralized volume control.
You have to keep in mind though that a) the unit is still using an ASRC, and b) its DSP power (and hence FIR capacity) is only marginally better than a single openDRC.
The filtering framework will let you use decimation to get more taps for low-passed channels, but that implies two additional SRCs (not asynchronous tho).
I am not convinced (A)SRCs are that big of a problem (and they often avoid much bigger problems in real world situations), but I must admit I am currently working on a software/hardware solution for my system that will avoid them is most cases, as well as provide a very large number of taps
Pos, that's a bit of a tease! Please tell us more about what you are working on- is it relevant to the M2?
There are currently 5 users browsing this thread. (0 members and 5 guests)