The RioCar parametric EQ's frequency response does not reflect settings in all cases.

I have conducted series of 1/3 octave RTA tests on the low frequency settings of the RioCar's parametric EQ. The results are disappointing.

Here is a short summary:

1). AttenuationProblem#1 "the 39Hz effect": While attenuation results in the expected Band Reject response at center frequencies above 38Hz, when center frequencies below 39Hz are selected, the EQ's response changes to that of a Low Pass filter.

2). AttenuationProblem#2: While the EQ is stable below -20dB, each reduction in gain, does not result in a reduction of output at the center frequency. For instance -26dB results in more attenuation than -27dB.

3). BoostProblem#1 "flat response": Between 18Hz and 59 Hz, all positive gain values reach a point above which the EQ shuts off. For instance, 42Hz at +9dB results in the expected Band Pass response, however at +10dB, the EQ no longer effects the signal, eg. flat response. The gain at which this behavior accurs is frequency dependant. For instance, at 54Hz the response is BP at +11dB, but at +12dB the response is flat. This problem does not occur above 58Hz.

4). BoostProblem#2 "the 39Hz effect": At gains where the EQ does work (see BoostProblem#1 above), the EQ also suffers from "the 39 Hz effect". While above and below 39Hz, the response is Band Pass, at frequencies below 39 Hz, the center frequency drops to somewhere between 27 and 73 Hz, dependant on gain. For instance, +8dB at 39Hz results in a +7dB boost at a center frequency of 43Hz (about what you would expect from this DSP chip). However, +8dB at 38Hz results in a drastic center frequency drop to 27Hz with only a +5dB gain. The gain dependancy refered to previously is as follows. As the gain is decreased, the center frequency rises. For instance, from the previous example - +8dB at 38Hz results in a 27Hz center frequency, but reducing the gain to +1dB results in a 73Hz center frequency.

With frequent reboots, these results were consistantly duplicatable. Though I will say I have seen some adjustments result in totaly wacked response curves...that if played through drivers would have had disatrous results. This OS is very buggy!

All the above analysis was done using the locked Q settings mode. In this mode, the Q value automatically changes based on the gain. Another factor I have noticed, but have yet to explore fully, is the effect of adjusting Q values. All 4 problems described above are effected by, and can be caused by, adjusting the Q value manually. For instance, while 42Hz at +9dB results in the expected Band Pass response (see BoostProblem#1 above), by increasing the Q above its automatic setting of 1.56, eventually at value is reached where the EQ shuts off.

I would be happy to send the spreadsheet that ducuments this behavior and the details of the test conditions. It is much easier to see this behavior visually rather than try and understand my written description.

I understand that some of this behavior may be by design. For instance, preventing people from blowing drivers with a gain of +12db at 18Hz may explain BoostProblem#1. A better approach would be to simply prevent setting the EQ beyond those design limits, rather than letting the user fall off a cliff.

Knowing some of this Non-Linear behavior I have measured, I may have a slightly better chance of achieving the response I desire in my system. But not knowing when the EQ's response is going to deviate from settings, does not make having this parametric EQ very useful for the rest of you.

Can the responsible party please post the logic behind this non-linear behavior?

Better yet, please let me know who can re-write the DSP programming routines so the response is linear across all gain, frequency, and Q settings.

Here is an attempt to upload the workbook, though it is 278KB.

Last try.
Does not include the flat response graph (easy to imagine), nor the Band Reject graph.

Before we go any further in this discussion... and before you do any more messing with it... what software version were you using?

Because there is at least one very serious known bug with locked Q mode in beta 11 that might cause any RTA analysis to appear really screwy.

I'm not saying that's what's happening (haven't read through your stuff in detail) but I just wanted to make sure you weren't on beta 11.

Tony,

I was hoping you would pipe in. This is the research I promised in the other related thread you started a couple of weeks ago. The forum thread linking skill escapes me.

I used:
- 2.00b13
- Hijack v285
- EFT 5.8120 in single channel, full duplex mode

The behavior is too ordered to be a bug. My theory is that it is by design. I know you have some done some RTA work. I am confident someone will verify (and/or refute) my results.

I have little knowledge of the software layers of the RioCar. Any idea if the DSP routines are in a accessable and modifiable (open source) layer?

Michael

Here is a more comprehensive description of the test conditions. See Attachment (NonLinearity-TestConditions.xls).

Michael

Did you mean to only send sheet 4?

Yes.
There are two sheets in two different workbooks. One is the test results and the other is the test conditions.
Michael

Well, the DSP is a masked, pre-programmed DSP core from Philips, built with firmware to provide a set of facilities for the designer and hence his user. It is applicable for car audio designs. The Application note AN9801 has just been posted elsewhere here recently which outlines the designed behaviour of the chip, as produced by Philips Car Audio.

The empeg player application, and specifically it's EQ, uses the DSP firmware by presetting registers with pre-calculated values generated from an application supplied by Philips to achieve specific Q, and band centre, values in an EQ filter set. The DSP firmware constrains the number of band centres and the limits of the Q behaviour.

So there may be:

- a problem in the firmware implementation (cannot be changed since the DSP is mask programmed and there is no FLASH in the chip)
- a problem in the coefficients calculation program used to calculate the preset values presented to the DSP by the player application
- a problem with the empeg player application EQ.

Given the attention to detail of the empeg crew, I am not inclined to think that the third case is so likely. It is more likely to be a firmware/design support application issue, something I have suspected for a while.

This means that if there is a genuine issue with the empeg's EQ response, then the player application would need to be modified by the empeg team in a work around to compensate for measured DSP firmware faults. They can only do this if:

- you present a firm case, logically argued
- you can illustrate exactly where the issues are by presenting transfer functions for the player in the active frequency ranges where there are problems
- you can convince the Two Johns that there is a problem when they are reading this board, or persuade Peter, then bribe them with Pizza and beer to correct it.

Don't forget that the player application is a closed source application (it's not available for us to modify), that there is no longer a development budget for the player or it's software, and that any bugfixes/added features are added by the empeg crew by them working on it in their own time. We cannot simply "demand" a change is made, and expect the change to pop out of the workshops in a couple of days. Those days are gone .

I am interested in seeing your envelope responses (In/Out) since I was carrying out measurements on my Mk1 about 2 years back in my Mini with a RTSA on a PC: the results were difficult to interpret and did not make sense. I chose to leave it alone after a lot of frustration, believing the major problem to be a poor, uncalibrated mike and a weedy sound card input. I had no calibration methods available.

Convince me! I am interested, as my original idea was to be able to produce a self-calibrating EQ by a sweep generation sampled by the microphone input. It hasn't happened yet - maybe my "wierd" results could be from a bug in the EQ?

If you have found something here, and it can be clearly seen, and there is a way to fix it algorithmically in the player application, then I for one would be happy to start a "fighting fund" of pizza and beer money for the team to put in the pot for them: if this was sufficient enticement, then maybe Rob could schedule a BugBlatt session one evening after work when the guys are not all up to their necks in their normal, daily, paid work for SB to have a go at fixing it.

Rob, have a peek in Bugzilla at number 1852.