TPA - USB Transport

[barrows]

I suspect it will be well worth the wait! I have an interim solution, so it is easier for me to be patient, but I am expecting great thinmgs from your XMOS implementation, very excited...
I am hoping for DSD support, perhaps via the dCS 24/176.4 packing method-it seems like this might be possible with the XMOS chip...

[adelias]

Originally Posted by barrows

I am hoping for DSD support, perhaps via the dCS 24/176.4 packing method-it seems like this might be possible with the XMOS chip...

The dCS spec for DSD with XMOS is not only possible but it is already available.

I've been beta testing it for a while now using mpd compiled with dCS spec DSD support. You can check it out at XCore.

[johnmarkp]

Russ,

I am making room in my new BIII case for just the Teleporter module to handle the future USB device you are working on. I have read that you may include the ability to synchronize the master clock on the BIII with the output rate of the USB device? I planned on putting the USB converter by my computer source and then run the CAT5 line up to the DAC. Will I be losing any functionality doing it this way. Thanks.

[MtBiker]

You could also just run a long USB cable. I have a TP PCM2707 USB DAC now fed by a 20ft $2 USB cable and it works fine.

[BrianDonegan]

Originally Posted by MtBiker

You could also just run a long USB cable. I have a TP PCM2707 USB DAC now fed by a 20ft $2 USB cable and it works fine.

That will depend on the the USB bus controller of your PC... some will have the juice for it, and others will not. Incidentally, TI recommends no more than 6' of cable for the PCM270x series.

[johnmarkp]

Brian,

Could you please answer my original question. Will running the teleporter from a remotely located box with you USB converter force me to lose some functionality?

Thanks

john

[BrianDonegan]

You should not lose any functionality that way. You will just supply the master clock via one of the teleporter lines.

[johnmarkp]

Brian,

Thanks, now I can complete this thing once and for all. One of the problems with your stuff is the nagging feeling that I will miss the next improvement if I finish the project now. On the other hand that is the great thing about what you guys do, you never stand still.

John

[Spirit02]

Brian - will there be provision to adjust the Buffalo volume control from this product?
Ideally I'd like a volume control accessible from windows that directly controls the buffalo volume level.

Cheers,
Phil

[OllBoll]

About volume control, I've been thinking about saying this a while and here it is at last =)

I argued earlier in this thread of how the interface should be connectable to the joshua tree and how this was better than simply using digital software domain volume in the OS. After doing tests and calculations I've come to the conclusion that you Russ and Brian were right and digital volume is far superior.

24bit is good enough to reduce lots without losing SQ.

Only case I still halfly argue that touching volume management would be useful is if the internal bit depth was increased to 32bit: The TPA receives standard 24bit from the OS, converts to 32bit, attenuates in 32bit according to instructions by the OS and then sends to say the buffalo. But even this would probably be overkill since except in very extreme cases 24bit is enough and some more.

I've been thinking about writing together a thread or article where I present my proof of why 24bit is enough even when reducing bit depth by attenuation in such a way that anyone similar to me that believed digital attenuation to be bad for SQ can be convinced otherwise. And if they still don't believe the article they can follow easy steps and test and listen (and measure) for themselves =)