Tír Na HiFi

http://www.tnt-audio.com/sorgenti/pinkf ... dge_e.html

".....
All audio digital-analog converters (DACs) receive their data in the I2S format. This is true for DACs with USB or S/PDIF inputs because the receiver chip converts the signal to I2S. With the I2S bridge, Pink Faun gives you a direct connection between a computer-based streamer and a DAC without any signal conversion. Any form of encoding / decoding that is applicable to other formats, such as USB, S/PDIF or Firewire, is a thing of the past, and sound quality is considerably improved. The Pink Faun I2S bridge is a PCI Express plug-and-play card. Pink Faun has chosen the Windows platform for the I2S bridge. Windows, as the most widely used operating system, offers a wide range of software packages for high-quality streaming, where the Pink Faun I2S bridge allows bit perfect transfer of audio media.
...."

Interesting thanks for the link.
I'll check it out.

2CA

2channelaudio wrote:Interesting thanks for the link.
I'll check it out.

2CA

thought i2s was only for a couple of cms

how can I get i2s into my nad m51 ?

sbgk wrote:

2channelaudio wrote:Interesting thanks for the link.
I'll check it out.

2CA

thought i2s was only for a couple of cms

how can I get i2s into my nad m51 ?

silly product,
i2s needs to be short definitely less than 50/60mm

dunno if pci-e would be sensitive to extention cable length but an external pci-e to i2s to dac with dedicated power supplies might work ok

I2S can be a few metres no problem. Again its down to implementation. We're talking about a few MHz here for the data and bit clocks so its relatively straightforward to maintain proper skew between the edges of the data and whichever sampling edge of the bit clock you intend to use . Good termination on the RX side is essential too. If in doubt, differential signalling could be used but that really is overkill here and anyway it doubles up on the number of lines required in a cable/pcb.

DaveF wrote:I2S can be a few metres no problem. Again its down to implementation. We're talking about a few MHz here for the data and bit clocks so its relatively straightforward to maintain proper skew between the edges of the data and whichever sampling edge of the bit clock you intend to use . Good termination on the RX side is essential too. If in doubt, differential signalling could be used but that really is overkill here and anyway it doubles up on the number of lines required in a cable/pcb.

Do you mean there still will be sound after a few meters
Or there's no loss in sq after a few meters
Or there's no loss in sq after a few meters if it's well sheilded and then re clocked
Any of the mucking about I did with i2s with lengths of 4 inches or more just wasn't at the
Pcie to i2s doesn't seem like a bad idea but I'd like to have the i2s source close to the reclock er if needed and close to the dac chip
But I think all sorts of funny things make a difference

nige2000 wrote:

DaveF wrote:I2S can be a few metres no problem. Again its down to implementation. We're talking about a few MHz here for the data and bit clocks so its relatively straightforward to maintain proper skew between the edges of the data and whichever sampling edge of the bit clock you intend to use . Good termination on the RX side is essential too. If in doubt, differential signalling could be used but that really is overkill here and anyway it doubles up on the number of lines required in a cable/pcb.

Do you mean there still will be sound after a few meters
Or there's no loss in sq after a few meters
Or there's no loss in sq after a few meters if it's well sheilded and then re clocked
Any of the mucking about I did with i2s with lengths of 4 inches or more just wasn't at the
Pcie to i2s doesn't seem like a bad idea but I'd like to have the i2s source close to the reclock er if needed and close to the dac chip
But I think all sorts of funny things make a difference

There should be no issue at all concerning data loss even after a few metres with a low amount of shielding and good termination. Any talk of I2S being unsuitable for more than a few cms is absolute nonsense unless it was implemented by an idiot. This is very very slow speeds we're talking about here. For comparison, the I2C (not I2S) lines in a HDMI cable can survive up to 15 to 20metres.

Now how you take that data of the I2S bus at the RX end is a different issue but on the subject of I2S lengths I dont see any problems. I'm implemented such an interface on an ASIC chip nearly 15 years ago.

Edit: Of course the biggest headache with I2S is that there is no cabling standard for it. So you get all sorts of ways to do the job like firewire, HDMI, or separate cables for each of the signals.

DaveF wrote:
There should be no issue at all concerning data loss even after a few metres with a low amount of shielding and good termination. Any talk of I2S being unsuitable for more than a few cms is absolute nonsense unless it was implemented by an idiot.

i knew that was coming

just think the noise/jitter gets worse with longer i2s cabling
not very scientific i know

Dave, If the I2S MCLK line is needed then this can be a multiplier of 128 or 256 of the sample rate fs
In other words for 192/384KHz it can be from 22.XXXMhz to 49.xxMHz speeds
I'm not sure how lengths of a couple of meters of cable will provide acceptable skew stay within acceptable limits?

The other issue with I2S is, as you pointed out - what's the correct termination impedance, 50ohm?
Without having some standard & having mismatched terminations will result in reflections.

How all this affects SQ is to be ascertained, I guess?

jkeny wrote:Dave, If the I2S MCLK line is needed then this can be a multiplier of 128 or 256 of the sample rate fs
In other words for 192/384KHz it can be from 22.XXXMhz to 49.xxMHz speeds
I'm not sure how lengths of a couple of meters of cable will provide acceptable skew stay within acceptable limits?

The other issue with I2S is, as you pointed out - what's the correct termination impedance, 50ohm?
Without having some standard & having mismatched terminations will result in reflections.

How all this affects SQ is to be ascertained, I guess?

The MCLK is optional as you probably know already but even at a few tens of MHz a few metres it isnt going to introduce skew that will result in problems, not at a couple of metres. In any case the skew between the data and bit clock is more important as this is whats used to transfer the data into the RX side and given that this is really low speed, you can have a fair bit of skew as long as youre not out by more than half a clock cycle. (assuming 50-50 duty cycle)

Where skew issues might come into it is if the DAC is the master and its driving the bit and word clocks back to the source. In this case the source needs to react to the rising edge of the bit clock, prepare and launch the data as quickly as it can before the subsequent falling edge of the clock as this is when the RX will sample that bit on its side. So depending on the implemention or what components the signal has to travel through on the PCB, this could all eat into your 'timing budget' as its called.

Impedence mismatches could be an issue alright and given that this protocol has no cabling or connector standard you could run into problems when mixing TX and RX designs from different designers/manufacturers.

On the subject of jitter, I dont think a few short meters is going to add much to whats already there but has been mentioned above, how the data is taken on the RX side is critical, i.e buffering, 2 stage PLLs etc etc.

I must read up more on how people use the MCLK. Maybe there is something there.