GS108 switch ports...
Posted by: ken c on 20 June 2015
perhaps i should spend some time reading 'the manual' but i dont recall having one.
warning: the following are probably really noddy questions, so please be gentle....
i bought some AQ ethernet cable to replace the bog-std ons that came with the gear.
the first i thought i would replace was one between NAS drive and Dratek router (i actually thought i had connected this to the switch -- but probably just forgot -- doesnt seem to have done any harm anyhow).
then i found that i couldnt connect it to just any port on the switch -- only worked on specific ones. i also found that even the old cable could ot be connected to any port on the switch only specific ones worked.
my guess, and this is what i would like someone to confirm, otherwise educate me please, is that since the AQ Cinnamon cable is Cat7 spec, only certain ports on the switch are compatible with that. if this is the case, then this change to Cat7 may not as straight fwd as i thought wih my current switch/router. is this correct?
enjoy
ken
Simon,
S/PDif: as you pointed out previously, where you have a protocol that's fundamentally synchronous, even re-clocking the data using a re-constructed clock (PLL, switched stepped incremental 'stable' clocks along with a degree of buffering etc.) only reduce the effects of the jitter, not completely eliminate it.
USB has a load of transport, information and system overhead inherent in the way it's implemented in computers, and (unless special drivers and other software - e.g. ASIO* are used along with compatible hardware) there's no guarantee of packet latency - in this way I believe it's closer to Ethernet than to S/PDif, simple buffering of the latter not withstanding!
* even here there's no actual guarantee of the latency from software to USB receiver, but it will be less than "normal" USB audio, and the buffers can be smaller as the chance of longer delays on any packet is greatly reduced.
Simon,
S/PDif: as you pointed out previously, where you have a protocol that's fundamentally synchronous, even re-clocking the data using a re-constructed clock (PLL, switched stepped incremental 'stable' clocks along with a degree of buffering etc.) only reduce the effects of the jitter, not completely eliminate it.
USB has a load of transport, information and system overhead inherent in the way it's implemented in computers, and (unless special drivers and other software - e.g. ASIO* are used along with compatible hardware) there's no guarantee of packet latency - in this way I believe it's closer to Ethernet than to S/PDif, simple buffering of the latter not withstanding!
* even here there's no actual guarantee of the latency from software to USB receiver, but it will be less than "normal" USB audio, and the buffers can be smaller as the chance of longer delays on any packet is greatly reduced.
Huge - to an extent but note I am referring to asynchronous audio USB - which uses USB isochronous transfers.
Its perhaps not that relevant anyway as most modern implementations of SPDIF use receive buffers that are independently clocked.
However SPDIF has a framed transport protocol as does asynchronous USB. These protocols are different but there are great similarities in the data framing.
Now the clock of SPDIF is for the transport protocol and is derived from the data types and structure to be conveyed, and not the actual carried sample data. The frames of audio data are no not sent equidistant to each other with respect to time because of the protocol structure. So in the 100% perfect SPDIF implementation the sample data would be jittery - its not a perfectly timed bit stream. Therefore it always needs to be buffered.
There is a formula or ratio to derive the DAC sample clock if required from the transport clock because the ratio of the framing and protocol structure is fixed for the sample data since there can be no regulation. In early implementation this ratio was used to clock the data out of the buffer into the DAC - hence the linkage between transport jitter and sample clock jitter. In most modern implementations this buffer clocking is decoupled from the lower later transport clock, that is the ratio is not directly used and is therefore asynchronous.
Async USB has also fixed timed frames and as you say a transport protocol - but is not suitable for deriving audio sample data clocks - since the ratio of the transport clock to the audio sample data clock can vary since amount of data per frame can vary when being regulated.
However both solutions require the data to be buffered and clocked out of the receiver.
Simon
Simon,
S/PDif: as you pointed out previously, where you have a protocol that's fundamentally synchronous, even re-clocking the data using a re-constructed clock (PLL, switched stepped incremental 'stable' clocks along with a degree of buffering etc.) only reduce the effects of the jitter, not completely eliminate it.
USB has a load of transport, information and system overhead inherent in the way it's implemented in computers, and (unless special drivers and other software - e.g. ASIO* are used along with compatible hardware) there's no guarantee of packet latency - in this way I believe it's closer to Ethernet than to S/PDif, simple buffering of the latter not withstanding!
* even here there's no actual guarantee of the latency from software to USB receiver, but it will be less than "normal" USB audio, and the buffers can be smaller as the chance of longer delays on any packet is greatly reduced.
Huge - to an extent but note I am referring to asynchronous audio USB - which is a USB isochronous transfer. Its perhaps not that relevant anyway in modern implementations as most receive buffers are independently clocked.
However SPDIF has a framed transport protocol as does asynchronous USB. These protocols are different but there are great similarities in the data framing.
Now the clock of SPDIF is for the transport protocol and is derived from the data types and structure to be conveyed, and not the actual carried sample data. The frames of audio data are no not sent equidistant to each other with respect to time because of the protocol structure. So in the 100% perfect SPDIF implementation the sample data would be jittery - its not a perfectly timed bit stream. Therefore it always needs to be buffered.
There is a formula or ratio to derive the DAC sample clock if required from the transport clock because the ratio of the framing and protocol structure is fixed for the sample data since there can be no regulation. In early implementation this ratio was used to clock the data out of the buffer into the DAC - hence the linkage between transport jitter and sample clock jitter. In most modern implementations this buffer clocking is decoupled from the lower later transport clock.
Async USB has a fixed timed frames and as you say a transport protocol - but is not suitable for deriving audio sample data clocks - since the ratio of the transport clock to the audio sample data clock can vary since amount of data per frame can vary when being regulated.
However both solutions require the data to be buffered and clocked out of the receiver.
Simon
I think we're largely saying the same thing, just disagreeing in terms of the degree of similarity between the three systems because of which differences we consider to be more important.
Indeed - I guess I scratch my head when some people look at async audio USB and assume it has lower jitter than SPDIF, because SPDIF audio is 'synchronous'. My point is that perhaps 15 years ago or longer ago yes SPDIF typically would have been affected this way - but not any more. Async Audio USB and SPDIF these days are both pretty much the same with them both asynchronously clocking the data out of the receive buffer - just using different supporting transport framing protocols and transport techniques.
Simon