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.