Hello Burning Sounds,
Thank you so much again for your really valuable new post from which I am learning a lot.
I have also read
your post at
Okto DAC thread.
My following notes here are not only for your kind attention but also for other people's basic reference and understandings;
Well, I am not an expert in "audio science", but I understand the
"phase" and "delay, latency, synchronization" are always critical issues in our "multi-channel, multi-amplifier system", and also in software crossover solutions.
Even though I cannot fully understand the details of technical basis (such as Q in
your kind post) in crossover and multichannel-DAC, I (we) at least
would like to have tools with which we can objectively measure the relative delay between the crossovered channels not only in line level (
i.e. after DA conversion before going into amps)
but also in real sound in our listening environment using a measurement microphone.
Having above thoughts in my mind, while still waiting for the arrival of my DAC8PRO (order #106, will shipped soon hopefully), I did my self-training trials using
REW-Wavelet analysis in line level signal and also in real sound using ECM-8000 microphone, as I showed in my
post #16 through
#23.
I found that
REW-Wavelet is very nice to check the "
cleanliness" of the line level signal before going into amps (
post #17), and very much importantly I
could confirm that there is essentially no delay between the crossovered channels given by software EKIO.
I could also confirm that
REM-Wavelet is sensitive and accurate enough to "
see" the tiny delay setting(s) in EKIO configuration (
post #18). The results shown in
post #18 also confirmed that EKIO's delay setting(s) is really accurate as measured by
REW-Wavelet.
After having the above naive
reliability evidences on REW-Wavelet analysis and EKIO's delay control, I moved onto
REW-Wavelet real sound analyses using ECM-8000 measurement microphone as shown in
post #19 through
#23, and found that I can control the delay of the real sound by EKIO's delay features.
REW-Wavelet is also very nice and sensitive to "
see" the listening room acoustics (
post #22).
I do believe that we always should check and confirm that
any of our delay (and/or phase) control would not affect the total Fq (frequency) response (
post #23).
Consequently, yes,
REW-Wavelet can be used in my project for delay and acoustic measurements after the arrival of DAC8PRO. I would like to emphasize, however,
before to fully utilize an objective measurement tool/solution like REW-Wavelet, we should confirm its accuracy and reliability in our (your) specific audio system through some well designed simulation trials and experiments.
And,
we should not be objective measurement addict, but trust our ears and brain, just like Burning Sounds nicely wrote "
in my particular circumstances the changes were small and not easily noticed by ear - but could be seen in REW".
I like the Siegfried Linkwitz's words of
"What is important to the eye is not necessarily important to the ear...", which is almost identical to my policy in this project; "
The simpler, the better as far as my ears and brain would recognize so in my listening environment" (please refer to
post #31 through
#39 on this policy).
Following on from our discussion on the
Okto DAC thread I thought it might be useful to discuss inter-channel delay in software DSP. Is it an issue?
When I first got into DSP I measured differences in processing delay in different brands of stereo DACS. It's the reason I started using mutli-channel DACs (I have three) as it solves that problem. I'll try and see if I can find some time to measure any inter-channel delays in my JRiver DSP. If there is any then delays can be added to individual channels to solve the problem. I only use IIR filters and I think it is probably not an issue. If you use FIR filters that could be different.
I think it is also worth raising the issue of differences between the various software and hardware active x-overs/eq and why it is not always straightforward to convert from one to another. It primarily revolves around how Q is implemented and they don't all use the same definition. Rane used to have a really good primer on this, but I notice that it has now disappeared from the web - but I have found it on the
Wayback Machine here. I also have a pdf of the article so if anyone is interested in it just PM me.
JRiver has info on how it calculates Q here - as you can see it does not use a standard definition of Q. This does only apply to shelf filters, but it is frequency and gain dependent so you need to use this nice little equation - 1/((((1/Q)^2-2)/((10^(d/40))+1/(10^(d/40))))+1) - Q is the actual Q and d is gain - to get the correct value for Q. As JRiver notes there are onlne calculators to do the math for you - I prefer to use the
Wolfram Alpha calculator to the one they recommend.
The only way I know to be sure you have successfully transferred DSP settings from one piece of software (or hardware) to another is to measure the transfer function. I did this when I switched from MiniDSP to JRiver - in my particular circumstances the changes were small and not easily noticed by ear - but could be seen in REW.
. Just to be clear the Q issue is not a delay issue, but one of different manufacturers using different definitions of Q. And some of the manufacturers' hardware boxes may use different definitions within their own product line up.
