Trinity DAC

[wizard]

Here's a picture of the new transport.

 

[CKKeung]

Thanks Wizard! You always have some insider info on every brands!

I personally don't like suck-in CD transport mechanisms. Disappointing.

 

[asiufy]

Yes, those are cheap
They're excused if Trinity implemented something like the MSB transports, with asynchronous playback.

alexandre

 

[edorr]

Yes, those are cheap
They're excused if Trinity implemented something like the MSB transports, with asynchronous playback.

alexandre

The MSB player is a (probably) a memory player, but the communication protocol with the DAC is not asynchronous. The I2S pro interface is synchronous.

 

[Elberoth]

The MSB player is a (probably) a memory player, but the communication protocol with the DAC is not asynchronous. The I2S pro interface is synchronous.

Where did you get that info from ?

In the following video, Larry from MSB says the clock is sent from the DAC to the transport, which means it is asynchronous.

http://www.youtube.com/watch?v=iZTQ5wp7i3w

The old MSB Network interface was synchronous. This is of the main differencies between the UMT and UMT Plus.

 

[Elberoth]

Can I ask what is the clock link feature?

The separate line that is used to send clock signal. It has been used on dCS components for the past 10+ years.

 

[Elberoth]

Trinity transport:





From what I was told, it should be unveiled in HK in 2 weeks time.

 

[edorr]

Where did you get that info from ?

In the following video, Larry from MSB says the clock is sent from the DAC to the transport, which means it is asynchronous.

http://www.youtube.com/watch?v=iZTQ5wp7i3w

The old MSB Network interface was synchronous. This is of the main differencies between the UMT and UMT Plus.

Yes, the transport is slaved to the DAC clock, but all this communication still happens in a continuous flow in real time, so this is a synchronous architecture.

 

[Elberoth]

Yes, the transport is slaved to the DAC clock, but all this communication still happens in a continuous flow in real time, so this is a synchronous architecture.

Indeed you are right. My understanding of the word asynchronous was wrong.

Which doesn't really change the fact, that the best interfaces for audio are those, whre clock is generated in the DAC and sent back to the transport.

Asynchronous USB is one of them. MSB's Pro I2S is another.

 

[edorr]

Indeed you are right. My understanding of the word asynchronous was wrong.

Which doesn't really change the fact, that the best interfaces for audio are those, whre clock is generated in the DAC and sent back to the transport.

Asynchronous USB is one of them. MSB's Pro I2S is another.

I don't think asynchronous USB sends a clock back to the transport.

If the trinity transport / dac combo does this (i.e. send clock to transport) using a USB connection, they would have to implement a proprietary protocol using the USB interface, much like PS Audio did with I2S over HDMI.

 

[Elberoth]

It is called asychronous because the dac's master clock isn't synchronized directly to any clocks within the computer. Instead, the dac is controlled by a fixed-frequency clock. This clock controls the datastream from the computer to a buffer near the DA converter.

 

[edorr]

It is called asychronous because the dac's master clock isn't synchronized directly to any clocks within the computer. Instead, the dac is controlled by a fixed-frequency clock. This clock controls the datastream from the computer to a buffer near the DA converter.

Correct. Unlike I2S Pro, USB is truly asynchronous, and the DAC generates the clock, but this is not send back to the transport/computer.

 

[microstrip]

Indeed you are right. My understanding of the word asynchronous was wrong.

Which doesn't really change the fact, that the best interfaces for audio are those, whre clock is generated in the DAC and sent back to the transport.

(....) MSB's Pro I2S is another.

This system was used by several manufacturers such as Sony and Krell in their top transports and DACs in the late 80's - early 90's. However it was quickly abandoned.

 

[Elberoth]

This system was used by several manufacturers such as Sony and Krell in their top transports and DACs in the late 80's - early 90's. However it was quickly abandoned.

Yes, it was abandoned by Krell and Sony, but only because they stopped making separates altogether !

Most manufacturers of top level digital front ends still use it - MSB, dCS, Esoteric, Stahl/Tec, CH Precision, Accuphase, Zanden - you name it. It is much better than than the ubiquitous SPDIF interface.

The only hi-end manufacturer that stopped using the clock link feature I can think of right now is EMM - and that is only because they developed thier proprietary technology (which I belive is RAM buffer based).

 

[LL21]

Yes, it was abandoned by Krell and Sony, but only because they stopped making separates altogether !

Most manufacturers of top level digital front ends still use it - MSB, dCS, Esoteric, Stahl/Tec, CH Precision, Accuphase, Zanden - you name it. It is much better than than the ubiquitous SPDIF interface.

The only hi-end manufacturer that stopped using the clock link feature I can think of right now is EMM - and that is only because they developed thier proprietary technology (which I belive is RAM buffer based).

This is interesting...for some reason, I thought the Zanden clock was in the Transport. The articles/reviews I have read refer to their double-oven crystal oscillator as resident inside the Transport and that the clock information travels on a parallel track to the audio information via the i2s connection. I am no techie so I apologize if I have missed something self-evident to others.

 

[Elberoth]

This is interesting...for some reason, I thought the Zanden clock was in the Transport. The articles/reviews I have read refer to their double-oven crystal oscillator as resident inside the Transport and that the clock information travels on a parallel track to the audio information via the i2s connection. I am no techie so I apologize if I have missed something self-evident to others.

Yes, because Zanden - for whatever reason, got it wrong. Instead of placing the clock where it can operate at its best (least amount of jitter) i.e. very close to the DAC chipset and send it back to the transport, they are sending it from the transport to the DAC. Since it is on a separate line, it is still better then the clock recovered from SPDIF signal, but nowhere near as clean as if thay placed it in the DAC as it has to go through PLL loop anyway.

 

[microstrip]

This is interesting...for some reason, I thought the Zanden clock was in the Transport. The articles/reviews I have read refer to their double-oven crystal oscillator as resident inside the Transport and that the clock information travels on a parallel track to the audio information via the i2s connection. I am no techie so I apologize if I have missed something self-evident to others.

Yes, AFAIK the clock is in the transport and the I2C feeds it to the DAC - as I2S has separate lines for clock, word and data, it should be equivalent to having the clock in the DAC. However, IMHO, the implementation is much more important than the topology in digital audio. No one will be able to tell how a digital unit sounds just looking at topology or measurements, unless it is very strongly typed or colored.

BTW, I was told yesterday by a good friend that HifiNews reviewed the new Metronome very expensive top units - time to read how Poly(methyl methacrylate) affects digital!

 

[microstrip]

Yes, because Zanden - for whatever reason, got it wrong. Instead of placing the clock where it can operate at its best (least amount of jitter) i.e. very close to the DAC chipset and send it back to the transport, they are sending it from the transport to the DAC. Since it is on a separate line, it is still better then the clock recovered from SPDIF signal, but nowhere near as clean as if thay placed it in the DAC as it has to go through PLL loop anyway.

Adam,

IMHO, this is not forcefully true - generating and sending high bandwidth signals needs special care and techniques to deal with delays, reflections and noise. Sometimes a finite length of cable is better than no cable. What are you calling "clean"?

 

[Elberoth]

Adam,

IMHO, this is not forcefully true - generating and sending high bandwidth signals needs special care and techniques to deal with delays, reflections and noise. Sometimes a finite length of cable is better than no cable. What are you calling "clean"?

When you place it in the DAC, you can use a free running clock (no PLL = jess jitter). The PLL goes to the transport (which has to synchronise its own clock with the clock signal incoming from the DAC).

Another advantage is that you can place the clock a few cm/mm from the DAC chipset itself, which also helps to minimise jitter.

 

[microstrip]

When you place it in the DAC, you can use a free running clock (no PLL = jess jitter). The PLL goes to the transport (which has to synchronise its own clock with the clock signal incoming from the DAC).

Another advantage is that you can place the clock a few cm/mm from the DAC chipset itself, which also helps to minimise jitter.

Perhaps I was not clear - the signal clock of the transport is sent trough a separate hardware line in I2C - there is no added jitter. Close proximity does not minimize jitter, although it can seem the logical way of doing it.

BTW, I read in the MSB site that they are DSD ready. What does it mean exactly? Why only ready, not full DSD?