[sfraser]

I have never heard of synchronous TDM circuit over a packet based IP network, care to explain?

Hi Sasha, not sure what your background is, but I would suggest you start with these:
 
http://en.wikipedia.org/wiki/Pseudo-wire

http://tools.ietf.org/html/rfc4553

http://tools.ietf.org/html/rfc5086

If you have questions let me know.

Cheers,

[skunark]

I have yet to have anyone successfully explain to me why all significant jitter cannot be removed by building an appropriate play out buffer just prior to the DAC? We do this all the time in the internet-working world when we build synchronous TDM circuits/services  over a packet based IP network.

Scott

In general, the DAC circuits will be impacted by at least these issues:
*Jitter from the clock oscillators
*Jitter from the driver/output stage. One easy fault is the rise and fall time will never be exactly the same, and this will cause jitter, and is even worse when data is sensitive to both edges.

Other issues that impact the dac and mostly an additive issue from the same issue as the DAC.
*SPDIF is a source synchronous signal.   i.e. clock is built into the the data wire, so you can get jitter based on the the source oscillator and driver
*i2s can be an improvement since the clock is a second wire and data is captured on consistent edges for a given channel.
*reclocking techniques that utilize a synchronizing fifo and buffering can improve jitter but you will always have jitter from the oscillator. 

TDM...  clearly you don't own a cellphone .. TDM is just a way to share different types of information on a given wire.  Most networking protocols can either handle a dropped packet or latency costs to resend the data, but won't address jitter within a dac.

[Sasha]

Hi Sasha, not sure what your background is, but I would suggest you start with these:
 
http://en.wikipedia.org/wiki/Pseudo-wire

http://tools.ietf.org/html/rfc4553

http://tools.ietf.org/html/rfc5086

If you have questions let me know.

Cheers,

Cool, thanks.
Is it used widely in North America?

[Sasha]

*reclocking techniques that utilize a synchronizing fifo and buffering can improve jitter but you will always have jitter from the oscillator. 

Is the argument here that after buffering the only jitter remaining is the one from the local oscillator?
If so, I have not seen practical confirmation of this?

[sfraser]

In general, the DAC circuits will be impacted by at least these issues:
*Jitter from the clock oscillators
*Jitter from the driver/output stage. One easy fault is the rise and fall time will never be exactly the same, and this will cause jitter, and is even worse when data is sensitive to both edges.

Other issues that impact the dac and mostly an additive issue from the same issue as the DAC.
*SPDIF is a source synchronous signal.   i.e. clock is built into the the data wire, so you can get jitter based on the the source oscillator and driver
*i2s can be an improvement since the clock is a second wire and data is captured on consistent edges for a given channel.
*reclocking techniques that utilize a synchronizing fifo and buffering can improve jitter but you will always have jitter from the oscillator. 

TDM...  clearly you don't own a cellphone .. TDM is just a way to share different types of information on a given wire.  Most networking protocols can either handle a dropped packet or latency costs to resend the data, but won't address jitter within a dac.

My point is TDM or "Time Division Multiplexing" circuits are very sensitive to jitter, yet we can emulate these circuits successfully over a packet based network by using a suitable jitter buffer on the egress. Retransmission is not an option.

Scott

[sfraser]

Cool, thanks.
Is it used widely in North America?

Yes it is. Typical users would be mobile phone back haul providers that have applications the still require TDM circuits. Other users  would be Power distribution and transportation  companies who have applications that have not migrated off of TDM circuits.

[skunark]

My point is TDM or "Time Division Multiplexing" circuits are very sensitive to jitter, yet we can emulate these circuits successfully over a packet based network by using a suitable jitter buffer on the egress. Retransmission is not an option.

Scott

TDM... it's multiplexing two different protocols by dividing the time each have on a wire.   That doesn't necessary guarantee that the data will arrive in a fixed interval.    If you ponder the simplicity of spdif or i2s can compare that to header overhead with any given network protocol, you might realize that the problem just got tremendously larger without even addressing the challenges of designing or interfacing to a DAC.

Is the argument here that after buffering the only jitter remaining is the one from the local oscillator?
If so, I have not seen practical confirmation of this?

oh god no, the clock network is just the start of the problem as there are still so many places it can creep back after buffering the data through a synchronizing fifo.  Just the introduction of jitter is now localized to the fifo and the dac, but is now more influenced by the clocking solution chosen (which is a good thing).   Without the synchronization, the jitter is based on the solution chosen for clock-recovery from the spdif signal which now widens the realm where jitter can be introduced, from source to dac.    Of course an excellent spdif solution can still outperform a poor solution that does reclock, it's all based on the quality of the components and design.     

[sfraser]

TDM... it's multiplexing two different protocols by dividing the time each have on a wire.   That doesn't necessary guarantee that the data will arrive in a fixed interval.    If you ponder the simplicity of spdif or i2s can compare that to header overhead with any given network protocol, you might realize that the problem just got tremendously larger without even addressing the challenges of designing or interfacing to a DAC.
oh god no, the clock network is just the start of the problem as there are still so many places it can creep back after buffering the data through a synchronizing fifo.  Just the introduction of jitter is now localized to the fifo and the dac, but is now more influenced by the clocking solution chosen (which is a good thing).   Without the synchronization, the jitter is based on the solution chosen for clock-recovery from the spdif signal which now widens the realm where jitter can be introduced, from source to dac.    Of course an excellent spdif solution can still outperform a poor solution that does reclock, it's all based on the quality of the components and design.   

Actually TDM is a method of transmitting multiple bit streams down a common  communications channel. If an accurate clock source is not used to sample the bit stream at the correct time, errors will occur. For the same reason reason if too much jitter is present  in  the bit stream, error will occur.

cheers and likely waaaaaay off topic : )

[skunark]

Actually TDM is a method of transmitting multiple bit streams down a common  communications channel. If an accurate clock source is not used to sample the bit stream at the correct time, errors will occur. For the same reason reason if too much jitter is present  in  the bit stream, error will occur.

cheers and likely waaaaaay off topic : )

All clocks have jitter.. period, but since it's purely digital here, and is timed on a common clock that where the data is encoded, etc, etc.  they delivery can be extremely reliable.. keeping in mind that TDMs are running in the multiple GHz rates audio is still in the kHz range... but it's not that all different than the reasonable i2s solutions.. and yes this is a huge tangent from the OP. 

[Chicago]

I can't believe I read all this and almost understood it until we got to TDM.  I really need to get out more.   

Mike

[tomsenko]

This thread convinced me.
Just ordered BDP-1

[sfraser]

I can't believe I read all this and almost understood it until we got to TDM.  I really need to get out more.   

Mike

Don't worry about TDM it's more ancient than the redbook CD player : )