does AES/EBU help if i implement reclock?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Hi!

Basically Coax is the better solution for digital audio interconnection, as it is designed for HF signal transmission, opposite to ordinary twisted pair cable. Even special 110Ohms digital microphone cable is always worse in transmission quality compared to Coax.

Regarding transformers, have a look at Cirrus' AN134, there you will find some references to background knowledge. Especielly Scientific Conversion has some interesting Papers about the influence of transformers on Jitter.

HTH,
Holger
 
Mostly true, but not for exactly those reasons.

Main problem with AES/EBU is the connector. While it is a 110R connector, it is unusable due to excessive reflections.

There are twisted pair cables designed for data transmission, that would work well if the proper connector was used. But sourcing them will be a problem, so coax does win out. As long as its impedance is matched to the impedance of the TX and RX circuits, as well as the connector.

Don't believe everything that Scientific Conversions says. In order for the jitter to be low, the reflections must be low. They provide no information on that, just a lot of their ideas about noise performance.

Jocko
 
Yocko, you wrote: "Main problem with AES/EBU is the connector. While it is a 110R connector, it is unusable due to excessive reflections."
I think you've forgotten a "not" in your sentence. XLR is no 110Ohms connector and never will be. Even Neutrik's XCC Series, especially designed for the use with AES/EBU, has a lower impedance. It is kind of stupid, that the AES has specified XLR as connector for this signal.

The TP digital audio cables have 110Ohms, but usually +/- 10%. And if you bend the cable you get some inhomogeneities within the cable causing a decrease in signal quality, whereas a coax cable has by nature a more narrow tollerance and better homogeneity.

At least in professional applications with longer cable runs I will always prefer coax together with BNC connectors and transformers at the end.

Holger
 
I hate to tell you, but it really does measure 110R. If you can eliminate all the extraneous garbage on the TDR trace.

Forget the impedance.......it will never work as the pins are so far apart that it will have too many reflections.

You are correct that the cables that you refer to will have problems. Back in my telecom days, we had twisted pair cables for balanced transmisson that worked quite well.

The reason that they worked is that you could not bend them. Much too rigid. Basically, the only place that we used them was in elevator shafts, to transmit data between locations many floors apart.

And, yes...........transfomers on the end!

Jocko
 
Hmm, I've had a discussion with a representative of Neutrik on this topic, he told me, that the impedance of a XLR is lower than the required 110Ohms. But I don't want to argue about that, we both agree that a XLR is unsuitable for AES/EBU, no matter if it has the correct impedance or not.

BTW, I have heard some rumour that the AES is thinking about a new connector for AES/EBU or using a coded XLR variation. If that was true, they would badly need a reality check, coming up with this idea ten years after they have issued their standard... :bigeyes:
 
They needed a reality check years ago. The first version allowed for.......what was it..............3 TX and 7 RX on each cable??? Something like that. I tried to tell the AES, but would they listen...............

Eventually, they figured out part of it, and went to one T/R only. Still, the whole concept is flawed.

I guess if you include all the stray capacitance in the impedance, it would be lower than 110R. But it is no longer resistive, so like you said, it still doesn't matter.

Jocko
 
Anyway........we have strayed a lot here.

What you are refering to is commonly called an asynchronoius reclocker. Elso is fond of them, as are a few others. I have no use for them. Seems like another flawed concept.

Secondary PLLs, or ASRCs, are the only real ways to get rid of the jitter on the DAC.

Jocko
 
stolbovoy said:
What about source clocking + reclocking from master XO placed close to DAC chips?

Why would you want to re-clock, when the ASRC with about 20-bits resolution is available? Another thing to keep in mind is that your anti-imaging filter and its analog power supply will degrade the overall S/N down even further, therfore ASRC is not the weakest link in your processing chain.

When the signal finally gets to the output RCA jack you will have 16-bits of resolution left providing you are lucky and everything worked perfectly.

THis is the reason why there are very few outboard DAC's out there with better then 16-bit output, and none of them ever showed even an 18-bits output.

All in all the re-clock will not work any better then the ASRC like AD1895(6), - in fact my take on it is that it will be next to impossible to match the AD1896 if you set the input and the output frequencies to be the same (no rate converssion) and do a good job generating a clean output clock.
 
The Monica2 is a NOS dac i.e No oversampling dac. No digital filter. Adding an ASRC would be a hanging offence.Why, if I were a nosser, I'd sooner replace the chocolate flake in my icecream with a dog turd. :D
Vadim, I fear in thinking like a sane rational engineer, you completely miss the point of the asynchronous reclocking referred to in the opening post. It totally defies reason and it seems like adding correlated jitter to me but its proponents, and there are quite a few in this place, all swear by it.
 
Vadim said:
in fact my take on it is that it will be next to impossible to match the AD1896 if you set the input and the output frequencies to be the same (no rate converssion) and do a good job generating a clean output clock.
How AD1896 can be better then simple reclocking when input and output frequencies are equal (same XO)?

Why would you want to re-clock, when the ASRC with about 20-bits resolution is available?
Because I don't know which algorithms they are using inside, and I want to experiment with my own. Also, I could test my tract up to DF for bit-accuracy :)
 
stolbovoy said:
I'm thinking about it :) May be I'd just made a switch to turn hardware DF on/off.

Why not go one step further with glitch free switching. The HDCD demoboard for the PMD100 had two digital filters on it and it had glitch free switching so you could switch between the two without interrupting the music. That way you could switch back and forth comparing the two filters. I've often thought such a facility would be useful in other areas. For example, you could switch between different filters or even switch out the filter on the fly depending on the music playing. I've always thought it would be nice to have a dac that allowed me to switch between the PMD100, YSF210, SM5842 and the SM5847.
 
rfbrw said:
The Monica2 is a NOS dac i.e No oversampling dac. No digital filter. Adding an ASRC would be a hanging offence.Why, if I were a nosser, I'd sooner replace the chocolate flake in my icecream with a dog turd. :D
Vadim, I fear in thinking like a sane rational engineer, you completely miss the point of the asynchronous reclocking referred to in the opening post. It totally defies reason and it seems like adding correlated jitter to me but its proponents, and there are quite a few in this place, all swear by it.

So we are up against a non-over sampling D/A, - WOW! I guess I should take my medicine now and or go back to school.

I truly fail to see a reason behind such design. It seems to me that a non-oversampling D/A would violate several principles of DSP, resulting in a rather noisy output. My guess, - 13 bits (on a good day) is all that is possible to get out of Monica2, - may as well stick with a turntable.

Certainly no amount of relocking will ever help matters. In fact, the contribution of correlated jitter to an overall THD+N numbers is completely negligible in light of the aliasing artifacts that will very much be present due to the 44.1 kHz sampling rate and 20 kHz signal bandwidth.

So, - in the case of a non-over sampling DAC approach, the relocking circuit is rather pointless. Come to think of it, - the ASRC used as jitter attenuator is useless just as well.

Vadim
 
stolbovoy said:
But isn't it ultrasonic noise, which would not necessary manifest itself in audible range?

Unfortunately the aliasing spectra are not ultrasonic at all. Here is the picture; - with no over-sampling the first image of the 20 kHz –wide data will appear at 44.1 kHz, contaminating the data substantially to put it mildly.

Without a proper anti-imaging filter the noise rejection is done by the D/A’s inherent zero-order hold function, that looks like [sin(x)]/x, with x=wT/2, w=2piF and T=period of the 44.1 kHz sinusoid. At 20 kHz this amounts to less then 0.2 dB. That means that the zero-order-hold phenomena only reject 0.2 db of noise at 20 kHz. This is all the noise rejection you will get if no anti-imaging filter is used. Noise city!

Even if you design in an anti-imagine filter, its order would be prohibitively high for the filter to have low or even linear group delay. To appreciate this you would need to ponder the requirement to reject about 96 dB or 16-bit equivalence in a space of about 4 kHz, which is a space between the edge of the first image and the edge of the data. Anyway, with such a fantastic requirement for an analog filter, I would forget about designing this filter if I have no over-sampling to begin with.

So, in a nutshell, here you have it, - with no over-sampling you cannot reconstruct the original 16-bit data at all. You may recover about 12-13 bits at the most, although I doubt that even that is possible.

Well, on the other hand, who is to say that listening to a dozen bits is a bad experience? I cannot speak for sound quality, but I can say this, - that a $100 antiquated turn-table will most likely do better in terms of signal integrity then a non-over sampling DAC.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.