Mark, is there enough information in the Kernel sources so you could send commands to the player's DSP?

Here's some things we're discussing over in the Wish List forum:

- The player's DSP has the ability to implement ordinary bass and treble controls. But the empeg player software doesn't do anything with those registers.

- The player's DSP has the ablity to change the "ramp" of the loudness control (how much loudness is applied at a given volume level), but the empeg player software only plugs in Philip's recommended default value there.

Is it possible for Hijack to alter these values? Since you've already hijacked the knob press for popups, I'd think it might be possible for Hijack to implement its own Bass and Treble sliders. And I would just die for a configurable upper cutoff point for the loudness.

Mmm.. bass & treble could be very useful in the car.

If some kind person sends me appropriate chipset documentation, with pointers to the bass/treble controls, I'll certainly have a look at it.

Perhaps fiddle with the EQ ramping afterwards..

The only known (non-NDA) documentation on the DSP is the PDF spec sheet. The spec sheet doesn't have detailed programming instructions (that's in the NDA documentation).

But I was hoping that somehow there were already some DSP programming commands in the kernel sources that would point the way, and a few of the memory location numbers from the spec sheet could help you.

I'm having trouble locating the SAA7705H spec sheet on the web at this time, so I'm emailing you my copy right now.

Yeah, thanks. But the spec sheet sadly lacks sufficient detail to do much, as others have discovered here in the past.

Don't ya just love closed-source.

Cheers

And there's nothing in the Kernel sources to give a clue?

>And there's nothing in the Kernel sources to give a clue?

Not the info we need, like the internal register addresses for bass/treble control.

On the plus side, while poking at this I "discovered" the cs4231a driver. This is the device that's using FIQs -- the likely source of player lockups. The fix is elsewhere, but at least now I understand where the FIQs are coming from.

This device is used to resample the audio-outputs, providing data for visuals for the Tuner and Aux audio -- and maybe for regular "mp3" visuals as well (don't know, don't care).

It is significant here though, because this is also the device we will use for recording live radio in the Empeg.. and it is a pretty standard device with published APIs etc.. so no barriers there!

I really want to be able to record Tuner output, even while listening to mp3's at the same time, and this device enables it to happen.

-ml

Time shifted radio while listening to MP3s? Be still my beating heart. Seeing as I don't have a tuner module yet, take your time and get this feature right...

If this comes true i'll need a tuner module for the empeg outside of the car too. Then I'll need another sled. Will it ever end?

Actually, no it doesn't allow you to do that.

If it did, we'd have had time-shift of radio on the wishlist. The tuner only outputs MPX (left/right/rds all in one signal) and this doesn't go into the sampler. The left/right extraction happens in the DSP, and can only happen when in tuner mode - ie, you can't listen to MP3 and sample the tuner.

The one way around this is to have an external board that plugs between the tuner and the main unit, and contains a FM demultiplexer whose output you hook up to aux in - as you can sample aux in whilst playing mp3s, this would work fine.

You *can* record tuner output, but only whilst listening to it. As the output sampled is the DSPs output, resolution will be affected by the volume you're listening to the tuner at.

Yes, it's a hardware limitation, but not one we could do much about without more hardware...

Hugo

Open or closed source isn't the point here; the docs were released to us under NDA. We can't tell you how to operate the DSP, even though we'd like to.

Personally, as the 7705 has now been superceded, maybe philips will release more info if someone can get hold of the right person. We spent at least 3 months trying to get the docs even when we actually had bought 100s of the chips!

Hugo

I think he was referring to the DSP being closed, not your player. That's the way I took it, anyway.

Actually, I meant the "closed" documentation in this case. For sure your hands are tied with the NDA.

*aching* to point out that you have already decided to try to have more hardware made... But I guess it wouldn't be worth the effort to put RCA-outs on the tuner (would probably requre another chip?

About designing this board... could the MPX signal simply be Y'ed off the connection between the tuner and the empeg? And then processed separately while the other "half" goes into the player as usual? Or would this degrade radio quality? or volume?

Marius (Escort Cab + Mark II)

Yes, the MPX could be 'Y'-ed off. Putting it through a buffer op-amp so that the impedance of the add-on's MPX input is so high as to be negligible is a good idea though.

Hugo

Would this do?

http://www-us10.semiconductors.com/acrobat/datasheets/SAA7705H_1.pdf

Nope.. already found that.

Did you guys see this in the datasheet:

Further information about the programming of the EPICS6
DSP core is available in “EPICS6 Programmer’s Guide,
version 1.3, July 3 1997, Author Ron Schiffelers, CIC
development Nijmegen”

Looks like the DSP is a drop in core with it's own documentation. Maybe we can look for the above document.

-Ted

Yes, that is correct. The document you described is, I believe, the NDA one. Not certain.

I looked long and hard for this doco and came to the conclusion that it was the NDA stuff Hugo was talking about.

Jeez, I wonder what the propietary aspect of it is? DSP cores are pretty much commoditized. So many vendors are begging you to use their cores. Oh well, it would be very cool thing to have. I was hoping if implementing a road-noise reduction algorithm using the microphone input and running it through a RLS noise cancellation algoritm.

-Ted

... road-noise reduction algorithm using the microphone input...

That would be an amazing hack if anyone could pull it off

Theoretically, it could be done using one of the adaptive filter techniques (RLS, LMS, etc) to generate an error signal (i.e the output from the RIO minus the input from the microphone). You then generate the correction signal to drive the error to 0 and add that to the output. It's actually pretty common: used on all phone lines for echo cancellation. Also, maybe someone used the BOSE headphones with active noise cancellation... same deal. Not sure how well it would work in the car given a much less controlled environment than headphones, but it's worth a try (if we can get to the DSP).

-T

This has been brought up before... most people say that the mic input can't sample that great of a freq range so it won't work... but I assume that most road noise comes from a limited frequecy range anyway....

Maybe someone could contact Phillips? Since Mark is just writiong programs that make their product more valuable (and not designing hardware to compete) I don't see why HE can't sign a NDA...

Maybe if the empeg guys can find a loophole to get Mark paid for alpha testing or something.... then he'd be on payroll and THEN he'd be allowed to view the code.

Pay him $.02 to make it legal. hehee

yep, i bet you can do reasonably well just with a 3 or 4 KHz bandwidth. i guess that's what experimenting with it is all about.

My friend who develop's electronics tells me that it should'nt be a problem to get a copy of the doc's for the DSP, if you just ask for it and tell you are developing for a product which uses the Philips DSP

Gosh why didn't we think of that..

Rob

Well then, why don't you just ring up your local Philips division, ask for a phone number in the national publications department, give them a ring and ask for a copy of Application Note NBA/AN9704, like I did?

Looks like I won't need to now. You're going to implement it for us!

Did you sign an NDA???

If not, be a champ and post some useful information - I'd really like to know the equaliser register format. There is 20 sections of 4 bytes, and finding out how those 4 bytes affect the eq section is a rather difficult bit of reverse engineering.

If you're under an NDA, please don't post this info...

I think he used to work for phillips, so he has connections :-)

I just asked Philips about this.

The document they don't distribute is the EPICS6 Programmers Guide,
but that is only required if you want to write your own DSP ROM code.
If you use the standard part, which I presume the empeg does, it comes
with DSP code which is documented in the user manual (NBA/AN9801).

Philips supply this manual free of charge. They sent it to me as a
pdf, marked UNCLASSIFIED and with no copyright markings or distribution
restrictions, so I feel confident I can put it here:
http://empeg.org.uk/info/saa7705h-man.pdf

Now, what can we do with it?

"Save Target As..."

Heh...

HEY GENIXIA!!!!!!

Yeah Baby. Groooovey.

Excuse me a while. I'm going to disappear with a good read.

Hmmm the stuff about a subwoofer output is interesting, even though it would be impossible to do it. Are any of the pins on the dsp unused?

Sean

Yeah, we knew the subwoofer output was THERE on the DSP, just unused.

Would be interesting to see if some minor rewiring plus a kernel hack could convert the Aux plugs to Subwoofer plugs!!!!

Nah it would take more than minor rewiring, you would need a preamp for another output, right?

I dunno, would you? And how tough would that be?

Don't suppose you can get the equalier utility off them as well? It will make it much easier since it will be able to calculate the equaliser settings automatically

- Trevor

Nice work. We don't try the simple, obvious things sometimes just because somebody said it wouldn't work.

Anyways, me quits working for money today and goes home to read.

The subwoofer support in the DSP is all digital. The SAA7705H can mix and
filter the left and right channels in various ways and emit the resulting
stereo bit-stream on pin IIS_OUT2. That pin can be used in at least two
modes: digital audio output or second I2S bus---I think this bus is used
only if there is a slave DSP, which the empeg doesn't (or does it?), so
the pin is probably free. The data sheet recommends tying down unused
pins, so there is a good chance that IIS_OUT2 goes to a resistor.

Even assuming there is an accessible track going to this pin, you would
still need to connect it to an external DAC, so there's no way this
could be done with the existing empeg circuits.

Someone said it wouldn't work because it DIDN'T work previously. We had to sign our souls away to get the documentation three years ago.

Rob

Well, now. Thank you for this incredibly valuable contribution to the group!

Now.. what to do with it? Here are the VERY OBVIOUS ones:

1.Proper Bass/Treble tone controls for Hijack.

2.Tone Generator controls, possibly useful for tweaking the equalizer response curves.

3. White noise generation using the tone generator (dunno if possible).

cheers

Also, It might be nice to provide config.ini adjustments to the "source scaling" block on a per-mixer-input basis, for use in getting the Tuner/Aux volume levels to match the MP3 levels (without having to tweak the volume control, either manually or within Hijack).

-ml

And also, we now have the info needed for adjusting the "bass booster" on a per-input basis.. a Hijack control for that would also be nice.


I can implement the controls, but we need somebody to step forth and provide the core functions for adjusting the various equalizer modes.

??

One more.. maybe provide control for the noise filtering capabilities for the AUX input (not sure if they apply to that signal, but something is definitely needed on AUX-in .. seems to pick up noise really easy).

-ml

Aw cool! We never even got a computer readable copy (mind you, I suspect it was classified at the time). I had to take the bindings apart and make photocopies so we'd have a security backup

Hugo

Maybe it is a suggestion to start a new topic, since now it gets interesting having the full documentation. Fiddling through this long thread feels a bit uncomfortable.

I've also taken a look... I'm impressed in what Philips has stuffed together in that DSP and making it, at the same time, quite easy to program too.

Lets take the new possibilities to higher level (EQ and also mentioned the unused pin for sub-woofer output->requires also an extra DAC !!).

Cheers,
EiSl

Yes, the subwoofer/centre channel output (mixed L+R) is ideal for use with the digital out board...

Hugo

If someone could modify the kernel to provide subwoofer out, we could take a crack at a dedicated sub out board.

Stu

Looking at the datasheet, it is implied that this DSP can turn into a full tuner by adding an RF and IF front end. 2 Philips chips are suggested (TEA6824 & TEA6811), but they are both discontinued. Nontheless, an FM receiver front-end should be cheapo. Integrating in to the DSP might be more complicated.

Are these the chips currently in the tuner add-on?

-Ted

No, it doesn't do demod, it's probably a badly written bit of datasheet. The two-chip TEA set are basically (well, later revisions of the same type of chip) what is within the metal cased tuner block in the tuner module.

The DSP only has FM-MPX, AM-AF and signal level inputs. It can't tune broadband signals - it only has ADC capabilities sufficient to get to the 38kHz (pilot is 19kHz, RDS is 38kHz ISTR, L+R is 0-19 and L-R is 19-38) FM encoded signal.

Hugo

To print this properly, you will need to get hold of the (obsolete) MS Line Draw TTF font, which may not be around on recent versions of Windoze/Word. It has been replaced with New Courier.

Yes a copy was posted here by smu

I wish I'd known that *before* my first attempt to print it.

I notice that the DSP also provides support for dynamic signal compression (boosting low level signals and attenuating high level signals) which kinda sounds like the Auto volume adjust feature of Hijack. but a little more sophisticated. The DSP seems to have quite a sophisticated 'quasi peak level' detection thingy which might prevent having to manually tweak the current auto volume adjustment for different types of music.

There's also mention of three different modes for the Loudness control - the static mode sounds like the way the empeg works currently, but dynamic bass boost (adjusted according to the amount of bass in the input signal) sounds very cool. I guess this sort of thing detracts from the audiophile purity of the empeg, but most mid-market head units seem to encorporate something like this to add warmth to the sound. Several people have commented that the empeg can sound a bit 'thin' without loudness applied, however the current loudness control reduces the amount of boost applied at higher listening volumes. Perhaps dynamic bass boost would be a better solution?

Good work on this everbody!

The empeg uses dynamic loudness. It's set up in empeg_mixer.c