Head-Fi.org › Forums › Equipment Forums › Computer Audio › perreaux SXD2 USB DAC
New Posts  All Forums:Forum Nav:

perreaux SXD2 USB DAC - Page 2

post #16 of 60
Quote:
Originally Posted by Wodgy
Jocko Homo is generally pretty knowledgeable. (BTW, his avatar is now Rudy Giuliani giving a Nazi salute.)
I think that's actually Guiliani dressed up as Mussolini, the Italian Fascist dictator:
http://www.diyaudio.com/forums/showt...threadid=46692
post #17 of 60
Quote:
Originally Posted by Wodgy
I don't think that's the right conclusion. If the jitter rejection of the ASRC is good and the device is well-implemented, this would be a very good device. The combination of PLL+ASRC is an "over-engineered" solution for eliminating jitter. Over-engineering is usually good.
by using USB chips's S/PDIF transmitter you're first making it worse and then trying to fix it by S/PDIF receiver's PLL.. that doesn't make sense to me.. on top of that their USB chip is the one with SpAct, which we believe is better than any other technique used by others including AKM.. at least if we look at stated numbers, I believe AKM is too in the 200ps range with Crystal stuff.. and by encoding to bi-phase you clearly are loosing performance.. the only advantage I see is the absence of S/PDIF cable and the ease of switching between digital sources.. I believe even AOS was telling that BB receivers sound better than AKM, so I suspect I2S out from the BB USB chip is better than what leaves AKM receiver..
and I certainly don't see any over-engineering here, leaving the jitter reduction task just to the S/PDIF receiver's PLL is rather under-engineering because we know that in such case, different transports sound different which is wrong, the main jitter reduction task is done in SRC4193 really.. I just wonder why they use PLL1708 and apparently 176.4/192 resampling depending on the source's samplerate, it's not synchronious in any case although they're trying to hold the ratio near integer, maybe it's better that way..
oh and just for the information - PLL1708's clock jitter is stated at 50ps.. not too impressive compared to 3ps claims on Tent Clock and similar aftermarket clocks.. implementation matters the most I suspect..
post #18 of 60
Wodgy wrote:
Quote:
The Empirical Audio guy on the other hand is borderline dishonest. It's not even clear his mods use an I2S connection. It's my belief that his mods use a TTL S/PDIF connection (but I'm open to being proved wrong). Nothing wrong with this, but some people seem to believe they're getting something else. Incidentally, he's also the guy who's been pushing the bizarre "digital cables need to be at least 1.5m long" mantra. Apparently no one has told the digital broadcasting/high speed data transmission community.
So, what exactly have I stated that is dishonest?

I never claimed any I2S connection in my products, only that I was investigating this. This is what is says on my website. Such claims can be damaging to a small business like mine.

As for bizarre digital cables, you need to read and UNDERSTAND this article. It is not BS:
http://www.positive-feedback.com/Issue14/spdif.htm

And I am insulted by your implication. I fully understand high-speed data transmission. I have designed such digital systems for more than 25 years. I was previously a Senior Staff engineer at Intel Corp. Now, I am just pursuing my passion, audio, and trying to advance the technology.
post #19 of 60
Quote:
Originally Posted by audioengr
Wodgy wrote:

So, what exactly have I stated that is dishonest?
I have never claimed that you were dishonest, and I apologize if anyone came to that conclusion. The qualifying keyword I used was "borderline", which I selected because it appeared to me that you were carefully choosing language which is in my opinion likely to create confusion. Specifically, you keep talking about eliminating the S/PDIF interface(s), e.g.:

Here:
http://www.audiocircle.com/circles/v...er=asc&start=0
you say:
"The SP/DIF [sic] interface and cable is eliminated...."

And here:
http://www6.head-fi.org/forums/showthread.php?p=984351
you say:
"I direct-couple the USB interface CODEC to the receiver chip, which eliminates one or both S/PDIF interfaces...."

This is, in my opinion, an unusual use of the word "interface," especially used in conjunction with the term "S/PDIF", which stands for "Sony/Philips Digital Interface." In light of that definition, in my opinion some people are likely to be confused that when you talk about eliminating the "SP/DIF [sic] interface" you're eliminating S/PDIF (in which the "I" stands for interface). This is not what you're doing.

Is my opinion unwarranted? While it is just my opinion about your use of language, there are examples of people who have indeed been confused in just this way. For example, in this thread:
http://www.diyaudio.com/forums/showt...threadid=45974
"tubesguy" has incorrectly concluded that you eliminate S/PDIF entirely:
"I think that you really want to do away with SPDIF entirely. I believe that one of the commercial modders (Empirical) installs the Transit inside the target DAC or home theater receiver, using, if I understand it correctly, an I2S connection from the Transit chip to the target's digital receiver chip."

Quote:
As for bizarre digital cables, you need to read and UNDERSTAND this article. It is not BS:
http://www.positive-feedback.com/Issue14/spdif.htm
I am not in a position to evaluate the technical merits of the article. However, it is not difficult to see that the article functions at least partly as advertising for your mod business, especially the last part where you extoll the virtues of modded gear but then warn people that "these types of tweaks are best left to qualified modders."

Quote:
And I am insulted by your implication. I fully understand high-speed data transmission. I have designed such digital systems for more than 25 years. I was previously a Senior Staff engineer at Intel Corp. Now, I am just pursuing my passion, audio, and trying to advance the technology.
Good for you. I wish you well.
post #20 of 60
And even if you install the transit chip and use the I2S connection directly it is still not very clear whether that reduces jitter.

The TI chip needs to recover the payload clock from the isochronous data flow on the USB bus. I have not seen any claims that it actually does this with particularly low jitter :-)

Cheers

Thomas
post #21 of 60
Quote:
Originally Posted by thomaspf
And even if you install the transit chip and use the I2S connection directly it is still not very clear whether that reduces jitter.

The TI chip needs to recover the payload clock from the isochronous data flow on the USB bus. I have not seen any claims that it actually does this with particularly low jitter :-)
Right on the money.
post #22 of 60
. EDIT
post #23 of 60
Something I don't understand here.

We take the clock out of the USB flow with the spact system (which is a pll, no ?). We probably have some jitter in there. Then we make things worse by encoding it into spdif, taking another pll to get another timing with even more problems. And then we feed that to the poor src4193 which is supposedly not very useful to filter the jitter.

Wouldn't it be easier to just put an ad1896 after a pcm2707 outputting some i2S ? What is the advantage of embedding the errors of the usb receiver into the spdif ? I suppose it is less costly to switch between two spdif flows than between two I2S flows but beside that ?

edit : isn't the second method what Apogee did with their mini-dac usb daughterboard ?
post #24 of 60
Quote:
Originally Posted by 00940
Then we make things worse by encoding it into spdif, taking another pll to get another timing with even more problems.
This is where Glassman is wrong. We don't make things worse by encoding it into S/PDIF. SpAct recovers a signal stable within, say, 75ps. This should be encoded to S/PDIF with little additional jitter. Why would a simple re-encoding add any serious jitter at all? This is sent to a receiver that typically recovers a signal stable to within, say 200ps. If the signal is already stable to within 75ps, it doesn't suddenly become more unstable unless the receiver is poor. The receiver is a filter. It may well do nothing, but it may actually improve things, so we may be down to 65ps now. We send it to the ASRC in the hopes of removing the rest.
post #25 of 60
look at how bi-phase mask stream looks like and how regular clock do, now don't tell me you can recover better clock out of the bi-phase stream then the original :-0

I certainly have no practical experience, but my common sense says nope this is not gonna work good.. you're basicaly saying that setting up a chain of say ten S/PDIF receivers and transmitters would clean the clock near perfect??
post #26 of 60
I thought it would be interesting to revisit this design issue now that Michael Grace has provided jitter measurements for the Burr-Brown receivers in this thread:
http://www6.head-fi.org/forums/showthread.php?p=1108208

He says:
"Measured at the spdif output of the PCM2902 the recovered clock from the PCM2902 measures about 240 pico seconds of RMS jitter when playing a 44.1kHz file and 390 pico seconds when playing a 48kHz file. Note that the 44.1kHz performance is very near to the noise floor of the Terrasonde Digital Audio Toolbox which is about 200 Pico Seconds when measuring spdif data streams. To really know the jitter of the PCM2902 would require access to the sample clock inside the chip. Oh well. However, this is not shabby jitter performance. I was expecting worse. With a good secondary PLL (like the s-Lock circuit) this can be reduced to less than 40 pico seconds."

Given those numbers (240-390ps word jitter), it makes sense that Perreaux designed their new DAC the way they did, since most recent S/PDIF receivers can usually drive jitter down to 200ps or better.

Of course, some might argue that using I2S to begin with would naturally have lower jitter and make this unnecessary. I don't really see how this could be, but it's too bad we didn't get I2S jitter measurements out of Michael to finally answer this once and for all.

That said, I think it's really great that Michael took the time to provide us with the measurements he did give us.

Also worth noting, these measurements suggest that the Grace 902 uses the same basic architecture as the Perreaux (i.e. USB receiver -> S/PDIF receiver). It just makes sense.
post #27 of 60
Wodgy : Ok, I need a clarification. Looking at the following block diagram, the PCM2707 uses a second PLL stage before outputting I2S and spdif. It's block diagram is very close of the dir1703. The PCM2902 looks far less complex. The second PLL doesn't affect its spdif output. In the case of the PCM2707, does your logic of the benefit of an additionnal spdif receiver still stand ?

The good DIR1703 :



The USB receivers:



post #28 of 60
The block diagrams look the same to me. They just omitted the clock input to the S/PDIF encoder in the PCM2902's block diagram. Clearly, the S/PDIF encoder needs to be clocked. Once you add that back in, the block diagrams are essentially the same.

BTW, I'm not saying that there's any definite benefit to having an extra S/PDIF receiver stage. I'm saying that it's possible there's a small benefit, and I don't see any serious drawbacks. Both the Perreaux and Grace designs make sense to me personally. That's really all I'm saying. However, if you're designing a USB DAC from scratch with no conventional S/PDIF inputs, especially if you're using it with the AD1896 ASRC, I wouldn't put an S/PDIF receiver in just for this one reason alone.
post #29 of 60
Duh, ok.

Btw, any idea why the jitter would go up by 1.5 when going from 44.1 to 48 ?
post #30 of 60
after all, we can evaluate every possible configuration and find out which one is the best.. rather than arguing over the papers
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Computer Audio
Head-Fi.org › Forums › Equipment Forums › Computer Audio › perreaux SXD2 USB DAC