DSP Tower of Babel

Re: DSP Tower of Babel

I am guilty of promoting the view that these platforms should be more consistent, so mea culpa.

It looks like there are more errors than the one or two I expected (lack of standard definition for Q, and top octave sample rate interactions).

This looks like platforms may be indiscriminately mixing and matching FIR and IIR filters with little consideration for how they differ in practice. Surely the manufacturer preset curve we are trying to replicate intended a specific response (amplitude and phase).

Besides that just the basic accuracy of these platforms appear to be lacking. I am surprised that the errors are not localized to my simple Q vagueness, but just about everything else, while the combination of all the different filters makes it harder to parse out what exactly is wrong. (note for Bennet's AES paper, plot each individual filter by itself.)

We need to name names and hopefully embarrass some of these people into cleaning up their act.

If the same manufacturer doesn't even agree with themselves between different models I submit they have a problem. This may be as innocent as the later release correcting an error in the earlier model, or just gross sloppiness. If they are too cheap to go back and correct the earlier model, they could list a correction factor on their website. If they don't know which one is right (if either) they are justified in keeping mum. :lol:

I am still optimistic that we will eventually get to enjoy the promise of digital consistency, but apparently not today, not yet. :roll:

JR
 
Re: DSP Tower of Babel

@bennett,

have any differences or trends become apparent regarding the 16k vs. FPPO settings?

Yes, it looks like FPPO (and to a lesser extent MTW) are no better in the LF for this measurement than 16K, and 16K is much better in the HF (as expected) for capturing that little resonance cut. I am using the 16K results for every processor. Measuring acoustically vs. electrically is a very different can of analogies, and that train has sailed.

Here are the latest results, two more processors. The overall level offsets are certainly due to different interface gains, and I will have to find a precise way to account for that. However, the gross differences in filter response, especially in the HF, are illuminating. You can also see that one of our processors sets its HPF definition incorrectly for Bessel.
attachment.php
 
Re: DSP Tower of Babel

I am just about to start writing this article, finally have all the graphics I need, including a great one from Dennis Bohn at Rane.

I thought you might be interested to see all the processor measurements I have, and their associated phase. It's one hell of a crapshoot, 9dB and 90° of phase differences between some.

I'm only using four traces in the article, I think that is enough to demonstrate the differences in every filter between them without making the graphics too messy to be clear.

Screen shot 2011-03-03 at 3.45.05 PM.jpg

Thanks again to Adam Robinson, Arthur Skudra, Christian Tepfer, Dave Stiles, David Karol, Harry Brill Jr., Ivan Beaver, Jay Barracato and Jelmer de Jong for providing these measurements.
 
Re: DSP Tower of Babel

Thanks for doing this, I remain disappointed that the industry is not bothered enough to clean up their act..

I still think you should name names for the worst outliers, while it seems almost everybody deserves demerits, and dishonorable mention.

JR

PS: yes, Dennis was one of the few who gets it and was already on the case, before I gave up trying to get the AES standards committee to define Q.
 
Re: DSP Tower of Babel

JR, the problem is... worst outliers from what? The processors that misdefine a Bessel filter are obvious, and perhaps the HF shelf behavior could be said to be wrong on a couple, but which one is right? I made these filters up, they apply to no real loudspeaker, and even if they did then the correct response is only from perspective of whatever arbitrary processor I used.

Some of the phase artifacts are especially interesting, but I hate to call those valid while relying on the delay times of 9 different contributors using 3 different versions of Smaart.
 
Re: DSP Tower of Babel

JR, the problem is... worst outliers from what? The processors that misdefine a Bessel filter are obvious, and perhaps the HF shelf behavior could be said to be wrong on a couple, but which one is right? I made these filters up, they apply to no real loudspeaker, and even if they did then the correct response is only from perspective of whatever arbitrary processor I used.

Some of the phase artifacts are especially interesting, but I hate to call those valid while relying on the delay times of 9 different contributors using 3 different versions of Smaart.

I appreciate the difficulty with that many variables.

I don't want to hijack your party but maybe even less variables , for a future Rosetta stone project.

My old thesis, which i need to rethink, was that center frequency and amount of boost/cut should "not" be subject to interpretation, so if there was any agreement between the tops of the one peak section and the bottom of the one dip section, all the other errors in between are Q, but I don't even feel that lucky.

In the short term there is more than enough meat for your readers to chew on for an article, but I still have a foolish belief that a translation table, or tables between sundry platform or some (fools) gold standard, could be made.

This shouldn't be that hard... Why do we tolerate it? I'm PO'd and not going to take it anymore....

JR
 
Re: DSP Tower of Babel

Bennett,

I am curious if you would like some measurements from old school processors just for comparison. I have a Peavey CEX-4L and a BSS380 lying around if you think they would be of any interest.
 
Re: DSP Tower of Babel

David,

The issue is just one of making the data palatable. There are processors that hav different filter shape depending on sample rate, shape that changes with frequency, severe math errors at Nyquist, and math errors with certain configurations of filter type. One processor, at least, changes the definition of the Bessel filter depending on its slope.

To characterize every processor to this level of detail would require more space than I have in the magazine, and not necessarily serve the primary point of the article which is "all processors are different". I think "some processors are really fucked up in the head" would be a whole separate article. I would certainly need to take the measurements for that article myself, since they would require a much more significant time investment.

I am very fortunate to have this community to draw from in order to get the measurements I have, which certainly illustrate the point of the article.
 
Re: DSP Tower of Babel

David,

The issue is just one of making the data palatable. There are processors that hav different filter shape depending on sample rate, shape that changes with frequency, severe math errors at Nyquist, and math errors with certain configurations of filter type. One processor, at least, changes the definition of the Bessel filter depending on its slope.


To characterize every processor to this level of detail would require more space than I have in the magazine, and not necessarily serve the primary point of the article which is "all processors are different". I think "some processors are really fucked up in the head" would be a whole separate article. I would certainly need to take the measurements for that article myself, since they would require a much more significant time investment.

I am very fortunate to have this community to draw from in order to get the measurements I have, which certainly illustrate the point of the article.
The problem In my mind is knowing what is the nominal or correct response. If there was a single good known result, people could just post their individual results, compared to this standard.

So this wouldn't be you dropping the dime on mfrs, but individuals, posting results from their own measurements. Let the world analyze the data.

If we don't have a laboratory standard then we decide on one "least bad" unit and make that the standard.

Of course this is all after you do your article... I wouldn't expect a magazine to embrace naming names either... but the community want's to know. (I think), I know I do.

JR
 
Re: DSP Tower of Babel

I wouldn't expect a magazine to embrace naming names either... but the community want's to know. (I think), I know I do.

JR

Hopefully the article will be a catalyst for a greater number of people to take interest in this issue, at which point, agreed, it would be great to push things further, make some noise to get the manufacturers to make this a greater priority. I think you're on to something with the concept of individuals posting results from their own measurements, as it has the possibility of a more "viral" effect, albeit with less control.
 
Re: DSP Tower of Babel

It looks like you have some good samples for your article. The only processors I can add to your data set would be from BSS Omnidrives (355 & 336). If you want them then I will do them and send you the v7 files to import. I'm personally glad that you are doing this article since it's something that I have had to explain way too many times. There are two things that always seem to come up. First and foremost is the way that Q is represented within different devices. On the Omnidrives the higher the value of Q, the wider the Q. Inversely for DriveRacks the higher the value for Q- the narrow the width. You have to know how your device is designed to get the results you are looking for from a DSP.

The other major issue is that DSP's can become flawed. I recently did a system analysis for a venue that was using 2 EV DX38's for the room. One was designated for the Left amp rack and the other was for the Right Rack. Part of the analysis was to run transfer functions of every device to be sure that each device was working properly. One thing that I found was that all though all of the internal settings were the same- there was an extra .04ms of delay coming from Output 3 on one DSP that did not match it's counterpart. The delay is going to cause a phase shift in that pass band.

This latency in the processor is another added dimension to why your DriveRack and KT processor will react differently, especially in a 2 or 3 way system. If you are doing a full system tuning (freq and phase alignment) within one processor than the latency is not so much an issue since it becomes apart of the process. In the case above it became a huge issue since the delay had an adverse effect on the phase and the frequency response.