TSS Two Chassis Super DAC

In streaming, the file is buffered somewhere and perhaps in many places along the path to you.

There’s no such thing as a free lunch. Ethernet is inherently more noisy than CD drives. It always implies a high speed processor which is also noisy. Those doesn’t mean Ethernet is worse or better than a CD transport, it just has a different set of problems to address. Many report that the best sound they have comes from a CD transport.

3 Likes

Yes sure, that’s what I mean…drives have other issues than streaming.

It is a DAC … and a streamer. Starting with a blank sheet, Linn saw no reason to separate the DAC from the streamer. Something I agree with and so do many manufacturers. You can use these Linn units as a DAC/pre-amp, with an external streamer (which is what I did for a while), but you don’t have a usb option.

I am mildly astonished by how persistently you get ignored on this point.

It would amuse me greatly if you started describing the link between the TSS boxes as “similar to TOSLink only faster”. (Yes I understand that the protocol is completely different, but are you still using NRZ signalling?)

I don’t think he is ignored. For most people here TOSLink does not offer enough bandwidth. I know I would be using it if it supported DS128…

1 Like

I totally accept that reasoning for an individual case, especially if you’re not lucky enough to get a DS that supports up to 192kHz on the optical input. Is it really so though that “most people here” have libraries with DSD128? I think I have like three tracks that I have toyed with via USB.

@tedsmith I see you typing, and realise I may have made more work for you with that question by not acknowledging the completely different clocking scenario. I understand that the clock which drives the downstream flow of data is itself generated by the Analog box and sent up the other optical cable to the Digital box. This avoids the biggest flaw of SPDIF, namely the need to adapt the DAC clock to the incoming data rate.

I use HQPlayer and upsample all PCM and DSD to DSD128. Yes, it sounds better than letting the DirectStream do it all…

No, there is no implicit or explicit bit clock over the optical cable, but the sending and receiving clocks are isochronous, so simply sending 6 ones followed by 6 zeros allows aligning on the 1/0 transition, after alignment it will remain in sync as long as the data is zero/one balanced over a reasonable time frame. The two channels of DSD data are sent differentially so there are six more bits for lower rate data and zero balancing. The up going clock is similar but at one fourth the master clock rate and hence can have about two bits of payload (one bit if zero/one balanced, but two bits now and then :slight_smile: )

For more detail, it’s something like what a SCAN921023 chip does.

Bootstrapping the FPGA to sync off the upcoming clock when it’s there and running off of a local clock when it isn’t is fun.

Since the length of the optical cable isn’t known, the FPGA has to phase align the data to the analog well enough for the receiver to sample mid bit.

2 Likes

Ah. I’ve recently started doing integer up sampling of PCM via Roon. I have to admit I’m enjoying that more than the built in algorithm… at least for now.

Another factor here might be how few ‘serious’ audio devices (such as servers and streamers) offer optical output… Most manufacturers, and consumers, seem to assume the toslink use case is TVs/DVD players and that’s it. Even devices intended to provide lots of outputs (in my case an Antipodes P2 after the EX) only offer electrical (AES, HDMI, etc) but no optical.

I’m not aware of any implementations that gang up optical connections (as dCS, PS Audio, and others do with 2x AES and as Chord do with 2 Coaxial) to support high bit rates. This would seem to offer the best of both worlds – complete isolation from electrical noise, and bandwidth – using a two-connector system that has been engineered and implemented on various over various other transport layers.

Notwithstanding Ted’s proprietary interface between TSSA and TSSB, why is no one doing this?

Sure. Another factor is that the optical implementations often suck on the receiving device so even though you get no upstream electrical noise, the circuitry controlling the optical circuit on the receiving end generates noise on its own.

I guess if we’re doing TSS FLAs then TSSA and TSSD would make more sense.

EMM Labs uses a special optical connection between their DACs, players, and streamer that has comparable bandwidth to USB. It might use I2S or some proprietary format. They sound really good. I wish other manufacturers would go this way, you don’t even need to double up the cables, one fiber optic is enough. Unfortunately, there is still a lot of myth pedaling about the perfect sound of ethernet etc. (DCS), which is clearly inferior to optical. What Ted is doing is smart.

1 Like