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?