Understanding the Dunn & Hawksford paper on SPDIF

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
" ... With plain LVDS on UTP, you just pipe bits in and they appear at the other end. You spend $5 total on parts. LVDS also has more than 50 times the required data rate. ..."

Go for it!! Show me a simple block diagram of LVDS, A to D and D to A over 30 feet of copper conductor (or whatever) that passes THX using 24 bit resolution in real time, bi-directionally. That's really the requirement in gross terms.

:smash:
 
you said a negative thing about feedback, then you said a positive thing about pre-equalization. Contradictory, don't you think?

Not exactly. Equalization and feedback are two different things. I'm not sure why you lump them together.

point-to-point LVDS connection properly terminated, you won't have reflection problems at any cable length

Haven't we heard this same thing regarding regular S/PDIF interfaces? Sorry, I'm just not comfortable with such blanket statements.

OTOH, I would think the greatest benefits to using LVDS is that it is differential and can pass DC. Both are significant advantages.

jh
 
I've asked this before, but why not have a hierarchical transport, analogously to the way computers have hierarchical storage (hard drives, RAM, CPU caches), so that the final transport level is a memory within the DAC itself? Thus, there is no analog timing information needing to go through the interface, which is simply any cheap bi-directional interface. The memory starts running low, the control circuitry sends a request to the previous level in the hierarchy, say a CD/DVD player or PC, for another chunk of data. This way any jitter sources remain within the DAC. The only difficulty I see is having a memory that can be read synchronously with reading timed by the DAC clock, and can be filled asynchronously without disrupting the reading process.
 
Your idea implies a totally redesign of the CD transport.
The standard interface send a continuous datastream, you want it to send packages... :bigeyes:
I think no IC manufacturer want do develope a new technology for data management of the "old" sweet CD .

maybe you only need a PLL and a large FIFO!
...a simplest way!
 
mrjam said:
I think no IC manufacturer want do develope a new technology for data management of the "old" sweet CD .
Well, this is a DIY forum. A microcontroller should take care of the package transfer, or one could just add USB or something to the DAC and transport sides. What I think is harder is the FIFO operation, since the read and write need to be completely independent, and the writing operation should not create disturbances that could create jitter on the DAC-clocked reading side.
 
Of course it is a diy forum :cool:
...but you need a totally new ICs set to control the operations of cd mechanics. What happen when the receiver do not allow the transmission of a new package (or is disconnected) ...you have to stop the dataflow from the cd decoder, pause the reading, wait for a package request ..bla ..bla ..bla
..maybe you're able to develope a micro to do it all ;)
I'm not! I think that a effective method using available chipsets is: send I2S to DAC, slave the transport, reclock the datalines and feed the dac with them + the local masterclock.
Or using spdif, a PLL with asynchronous FIFO like the 64K Cypress CY7C466A - maybe also the one you're searching for your idea! :bigeyes:
 
mrjam said:
Of course it is a diy forum :cool:
...but you need a totally new ICs set to control the operations of cd mechanics. What happen when the receiver do not allow the transmission of a new package (or is disconnected) ...you have to stop the dataflow from the cd decoder, pause the reading, wait for a package request ..bla ..bla ..bla
..maybe you're able to develope a micro to do it all ;)
I'm not!

Perhaps you have heard of CDROM drives ?
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.