Drive NOS AD1865/62,PCM1704/02/63,TDA1541 from FIFO: Universal I2S-PCM driver board

guys, he doesnt even know if he'll get the numbers to get it done at all, how could he know the price? or you mean for the BOM?
:) That's true.

Ian do you know aproximate price?

I Might be interested too (not afraid of smt soldering )
So up for aproximate price too !

Hi guys, glad you are interested in the new NOS gear:D. You can start the interesting list now to see if there is a chance for the GB.

Please don't worry about the price, see my previous GBs. I'll take care for sure:).

Good luck.

Ian
 
Ian,
Could these boards be configured to drive the 1541A dac chip in Nos mode? If so, please add me to Andrea's 4 boards for another 2.

Do you mean

"When input OB/TWC input is connected to VDD1 the two channels of data (L/R) are input simultaneously via DATA L and
DATA R, accompanied with BCK and a latch-enable input (LE). With this mode selected the data must be in offset binary.
The converted samples appear at the output at the positive going transition of the latch enable signal."

---TAD1541A data sheet P4

Ian
 
Hi Ian,

Oh dear, I must apologise for a pretty total ignoramus regarding the technical aspects of the dac chip so won't take up more of your valuable time, but yes, I think this is the standard way the chip is configured when driven by either the SAA7220 o/psampling chip or in my use, directly from thre SAA7210 decoder chip (NOS).

I was hoping that this could be a "simple adaptation" (!, sorry) on this configuration that your are developing here for other people and not a troublesome project of it's own.

Thanks ... james
 
James,

When in doubt, check the first post ;) I think that is the exact purpose of this project, unless I'm mistaken. There was a lot of discussion in the FIFO thread about the requirements for different chips and I thought most were catered for.

2. Support PCM63,AD1865,AD1862,PCM1704,PCM1702,TDA154 and other 2-2R DAC
Chris
 
Last edited:
James,

When in doubt, check the first post ;) I think that is the exact purpose of this project, unless I'm mistaken. There was a lot of discussion in the FIFO thread about the requirements for different chips and I thought most were catered for.


Chris

Thanks Chris :)

Hi Ian,

Oh dear, I must apologise for a pretty total ignoramus regarding the technical aspects of the dac chip so won't take up more of your valuable time, but yes, I think this is the standard way the chip is configured when driven by either the SAA7220 o/psampling chip or in my use, directly from thre SAA7210 decoder chip (NOS).

I was hoping that this could be a "simple adaptation" (!, sorry) on this configuration that your are developing here for other people and not a troublesome project of it's own.

Thanks ... james

Hi James,

I guess you want to use the L/R simultaneous mode rather than the I2S. Yes, the daughter board should support 1541 on this mode. However, at this mode, 1541 need offest binary input format. Please correct me if I'm wrong :).

In this case, I need write an additional code for format converter module of the FPGA/CPLD. Will do it once I get time. Please let me know your comment.

Regards,

Ian
 
Well, I'm very happy that you would consider my special requirements and even happier to use it as an alternative to John Brown's (EC Design) technique of isolating the computer from the dac via his SD card system especially as Jeremy's idea (qusp) of using an internal digital Xover that outputs 2 discrete signal paths (Hi Pass & Lo Pass signals) to 2 seperate dac chips via 2 seperate FIFO brds - it would be even better if a common master clock could run both the FIFO brds and the dac chips, possibly via divider/reclock.

I think there are quite a few folks that do prefer the sound of the old, fully tricked out 1541A dc chip running NOS and to have a top class interface that avoids the usual sound degradation problems of computer source is very promising indeed, particularly if it allows to 'maximise' the analogue nature of this dac chip/system.

I have heard a couple of the current computer source systems that use various ways of reclocking/isolating the computer but for some reason the 1541A dac in NOS mode is quite picky and seems to exphasize the problems, particularly when optomised - I thought it would be the opposite but unfortunately not, and no idea why.

I must apologise for my lack of technical knowledge and will follow up on your posts (do my homework!)

Many thanks ... James
 
James, Ian is usually very receptive to feedback and lightning quick at knocking up PCBs or models, ive not seen anything quite like it. so I encourage you guys to get involved and make this design do what you need, if you dont tell him, he cant know what you want. if the ideas are sound and well described, I dont think ive met another designer on here so open to consider/try other peoples ideas, particularly one that is so accomplished in his own right, so completely free of ego in that regard. He just wants the best result and that includes its interaction with the user and their goals.

and yes this is that board I was telling you about, its basically custom built for your needs driving NOS DACs and so much more flexible than any regular digital filter

it makes sense that NOS would be a bit more picky, as artifacts are more likely to be down in the audible bandwidth, instead of pushed up out of it. this is also why power supply is so important I guess, I guess NOS or NOT becomes a factor of PSRR in that way.

hell i'm considering playing with this thing for my ESS
 
Last edited:
James, I think I failed to understand the nuances of your question, I'll defer to those more knowledgeable on these matters.

Jeremy's idea (qusp) of using an internal digital Xover that outputs 2 discrete signal paths (Hi Pass & Lo Pass signals) to 2 seperate dac chips via 2 seperate FIFO brds - it would be even better if a common master clock could run both the FIFO brds and the dac chips, possibly via divider/reclock.

I don't this is quite Jeremy's idea. I think the idea is to have a single combined FIFO that accepts multichannel i2s input. The single most significant downside to the FIFO is that there is no deterministic way to synchronise two of them (or synchronise the FIFO with a video stream which is a more common challenge). So while it's in output very similar to having two but my understanding is that the datastream would all need to basically go through one FPGA configured as FIFO with buffer for multiple channels and clocked by one masterclock board (as you've said). That's a bit outside of the scope of the I2S -> PCM driver board though ...


I second what Jeremy (qusp) has said above too, Ian's one of a kind in terms of collaboration with users and almost unbelievably quick turnaround!!
 
Last edited:
thats correct, as it stands I cant really use this for multichannel/digital XO, but the thing is so darn good i'm continuing to collect pieces to use in the meantime to the rest of my system is ready and after that use it for my headphone rig

hopefully one day Ian will be seduced by the idea of running his ESS multichannel :)p)

James probably just read some of my dreaming out loud in his research. I have other multichannel USB and masterclock modules in my 'collection' to get me by for now (silly as that may sound)
 
Last edited:
I was hoping you would pick up on this and thank you very much for your kind words - it's a pity my "ol' noggin" wasn't a bit more adaptable and could absorb/understand this digital info better, but will plug on.

Yes, Ian is a real whiz-kid eh? Dunno how he does it, but really happy about it.
 
Well, I'm very happy that you would consider my special requirements and even happier to use it as an alternative to John Brown's (EC Design) technique of isolating the computer from the dac via his SD card system


To me this is a key attribute of this FiFo->PCM. It allows a true local master clock for the DAC but without the hassel SD cards and add and the flexibility to use whatever playback software you prefer. This would basically plug right into the EC DAC board in place of the SD player. It re-defines what we think of when we define a transport and DAC.