PCM Audio: Voltage Level of Logical TRUE? - Page 2

I am sorry I was not clear. The graph was definitely with a terminated input. And a good one since this is a lab instrument and not some sound card or consumer electronics gear. Again, there was nothing to say. I made a measurement on an audio analyzer which has 75 ohm termination. If someone had doubts about that, they should have asked me to clarify and not assume it is wrong.

As to posting it elsewhere, I don’t recall doing so in this forum. If I have and have forgotten, please consider it as a sign of me getting older . Where you might remember it from is me showing it to you on WBF Forum. The context there was that you implied that we can be pretty sloppy with digital audio interconnects (click on the first link in this search to see the interchange : https://www.google.com/search?hl=en&tbo=d&rlz=1C1SNNT_enUS374US375&q=site%3Awhatsbestforum.com+Synergy+-+Page+15&oq=site%3Awhatsbestforum.com+Synergy+-+Page+15&gs_l=serp.3...11870.15539.0.15704.17.17.0.0.0.0.179.1261.14j3.17.0.les%3B..0.0...1c.1.Ebd41pzFQkE). Quoting from that thread, you said:

Bolding mine. There seemed to be implication that just because the data we carry is low bandwidth, that we don't need to follow good practices with respect to digital audio connections. Missed there was that this is a serial digital stream carrying two channels of data so its bit timing is quite a bit higher than what one imagines from the payload (i.e. individual PCM samples presented as parallel set of bits). And that reliably getting digital samples is not sufficient to say the job is done perfectly. Successfully extracting bit timing from the transitions requires good bandwidth far above our payload bandwidth.

In that thread, I did go on and provide more detail of my measurements including the actual frequency response of the low-bandwidth cable:



Lot of text went on with that graph. So there was nothing hidden or not stipulated Ethan. In that thread and here I used properly terminated end points. And the assumption, if one was familiar with that test instrument would have been the same (see Don's post).

Amir's point about digital audio bit streams having rates corresponding to frequencies well above the audio frequency band, albeit much lower than your microwave oven, is valid. Still doesn't mean your average "audio" interconnect won't work OK for you, as Ethan notes. Violent agreement achieved. Minor points:

1. A lot of audio interconnects have around 75 ohm impedance and the RCA connector discontinuity is not enough to cause issues for short runs and typical digital audio bandwidths (few MHz). I think a lot of companies just buy bulk cable and use it for both audio and video, probably from S-video days. That is not a bad thing.

2. There's a lot of error correction going on to mitigate bad connections and avoid data loss.

3. When used as the DAC clock, the recovered clock's jitter can reduce SNR and add distortion, and the cable is a factor in ISI (intersymbol interference, leading to correlated or deterministic jitter). Audibility is always open for debate...

FWIWFM - Don

A minor correction: S/PDIF had no error correction, but does have a couple of levels of error detection. Each data sub-frame (32 bits) has a parity bit and a "valid" bit. A problem detected by the source is flagged with the valid bit by the source, and errors in transmittion is detected using the parity bit. A parity error would typically cause the receiver to drop a single sample.

Ooops, too many standards, thanks Mark!

Does it have a provision to request the packet be sent again? (I'm in the SAS/PCIe world now...)

Unfortunately, no. For one, the link is uni-directional. For two, the latency would be a problem. Originally, the data went to the DAC with no buffering, so there was no time to retry.

Fortunately, being a serial link, it either worked or didn't work. I have found parity errors to be bordering on non-existent.

Its vastly overstated. In order to get FCC Part 15 certification the output of the DAC has to be low pass filtered. The low pass filters commonly used cut off starting in the 8-20 MHz namge. That's about 1/200 th the frequency of a microwave oven.

No, Amir is writing from deep in the land of hyperbole, and Ethan is talking real world. There can be no agreement between people who do good listening tests in the real world and people who avoid them assiduously in their own lives.

Agreed. Fact is that impedance is not an issue in the lengths and formats being discussed. 300 ohm twin lead works, so does bent coathangers if you can avoid shorting.

Absolutely not! There typically just aren't any errors. There isn't any actual error correction of digital data passed over a SP/DIF link. Typically, there is no effective error detection, either. Why detect errors? Nothing can be done about them by the equipment!

Most error detection related to SP/DIF links is by means of listener observations when they hear clicks, thunks, and periods of silence.

It is the responsibility of the equipment receiving the digital signal to recover a proper clock signal, and this can and is frequently done brilliantly. One of the best examples of de-jittering digital audio is what optical disc players do to the signal they receive from the phototransistors in the transport.

Compare and contrast ripping a CD with good software which typically involves error detection, correction, and even retries with playing a CD on a regular CD player which has no facility for retries but can do error detection and correction with SPDIF that does none of the above.

The issue of jitter arose in the days (1980s-1990s) when separate DACs were generally incompetently designed. By Y2K mainstream receivers lived or died based on how well they received and de-jittered SP/DIF and they generally did far better than the overpriced junk that preceded them.
Edited by arnyk - 11/15/12 at 4:29am

By comparing:



(posted and discussed a week and 2 days ago)

to



(posted nearly a week later)

we can see that after nearly a week of of waiting with no replies at all from Amir, we finally have some reliable evidence. I agree that the evidence above shows that the origional test was done with a 75 ohm in place.

As is not unexpected there is considerable muddying of the water with a number of irrelevant false claims such as a claim that using lab equipment guarantees good results and that using other means guarantees poor results. In fact the actual terminating load used in the test is a user adjustment of the test equipment of any kind, which as usual can be done any way that the user chooses or fails to choose.

As usual, it needs to be pointed out that turning data with a wide variety of technical conditions into clean audio is something that well-designed digital audio gear can and does do.

As usual rather than shedding light, demonstrations of technically deficient signals in isolation without any reliable evaluation of actual sound quality in practical use serves only to raise concerns related to issues that have been resolved in mainstream consumer equipment for over a decade.

Yawn!

Sell! Sell! Sell!

What about the connecting wire? I asked about that too but you didn't answer.

--Ethan

Sorry I don't follow. What connecting wire?

Aside: I actually think there is less disagreement among the folk than it appears from the posts, but maybe the drugs are kicking in...

Hi Arny, I find the error detection mechanisms actually work well. But as you say, errors on the cable border on non-existent.

However, errors on the source disc are common, and most S/PDIF source devices I've looked at seem to support the valid bit. Most S/PDIF receivers seem to support the parity bit (which all source devices need to support).

There is something the receiving equipment can do when an error is detected: It can mute the sample, to spare you from listening to noise (the parity and valid bits exist on a per-sample basis).

How soon they forget:

So was your "look how bad this is" graph made with a normal RCA wire, or one with an integral low-pass filter? And if it was made using a "special" wire, why didn't you say that either here or at WBF when you first posted that graph?

--Ethan

I have worked with literally 100s of audio components with SP/DIF and TOSLINK inputs, and have never had one that took any visible action when the link was receiving bad data. I have worked with products that had lights that indicated the presence of an input signal, but they would remain on even when bit errors were being received.

Got an example?

I've seen devices with digital inputs mute, but they only muted when there was no data.

I have been very clear on characteristics of this test. And I have repeatedly so in this thread too. But somehow you are skipping past it.

This is what I said in my original post: "In this case, the second trace is a low bandwidth cable which has caused the waveform to distort and with it, also lowers the peak to peak value.". In the WBF Forum post I said the same thing: "The nice looking square wave in blue is the normal coax, and the green, reduced bandwidth audio cable. " I went to say, "We see that the response is flat with 20 ohms for both cables. But at 600, Transparent cable shows a drop of about 0.2 dB at 40 Khz which matches your criteria of 2X audio bandwidth. Yet we see that by not maintaining that level at higher frequencies, jitter is sharply increased. "

How could I be more clear than that? I mention repeatedly the cable is low bandwidth and even show you the frequency response. What difference does it make how its bandwidth was reduced? You had the actual measurements and that is all that counts in this regard to show that bandwidth is important in extracting proper timing of digital samples. This was the point that was missed from your position in the WBF thread and I wanted to make sure it was not missed in this thread either as we look at long cables.

In addition, the brand and model of the cable was in the graph and highlighted: "Transparent Link 100 Audio Cable." Here is the graphics again:



You could have easily searched for the characteristics of the cable that way yourself.

There is no attempt to hide anything Ethan. As you noticed, Arny corrected himself and now agrees there was nothing wrong with termination. I thought that was your jumping point to raise this objection.

Hi Arny, For the most part, I would not think anything would be visible. Audible, sometimes. But more on that below.

Typically, those lights are an output from the S/PDIF receiver's PLL. It indicates that the PLL is locked to the incoming frequency, and not whether the data is any good.

I called my client to ask if I could use the results of the tests. I have not heard back. But here is what I can disclose:

My Audiotron supports the transmitting of the valid bit. If it is not actively playing music, it still sends an IEC958 stream, but the valid bit indicates "invalid".
My SH-AC500D indicates that no audio is present on the front panel when it receives the valid bit as "invalid".

The parity bit is supported by any device that uses a Freescale Symphony DSP with a built in S/PDIF module. I've been using the dual-core DSP56721, whose reference manual I can quote from: So the goal is to try to accommodate the error in such a way that you don't hear it. So there is something you can do about a parity error.

Would your ears be able to detect it if only one sample was muted? Also, do many of your devices put out noise when the data is bad?

This was one of my quick & dirty tests:
Partly pull out one end of the optical cable, and find the point where the signal is marginal. If you hear a lot of noise, parity is not being supported. But if you hear it alternating between sound and silence, than parity is supported.

I disagree. Using a trick RCA cable that may not even pass simple analog audio cleanly for a digital audio cable is well beneath the pale. I'll bet that that post's somewhat opaque wording slipped by a high percentage of the people who read it. Given the lengthy queue of posts from the same source that harped on degradation of digital audio by cables, the whole situation is both highly likely to be confusing to newbies, and IMO regrettable.
Edited by arnyk - 11/18/12 at 9:51am

Exactly. I certainly missed it the first few times. When someone uses measurements and data to support a claim, it's expected that they use accepted practice. To intentionally skew data to make a bogus point by using a trick cable is dishonest as well as incompetent.

--Ethan

There was no claim. The graph was a response to your post on WBF implying that all that matters is getting audio to come out and bandwidth is not material if that happens:

I wrote this before I post that graph:

"Funny that this discussion has come up as for the last couple of days, I have been working on characterizing S/PDIF cables. Here are the results of using a generic RCA cable, vs a Transparent audio interconnect cable (NORMAL audio, NOT S/PDIF) which has a black box that filters high frequencies."

Note what I have bolded here. I could not have been more clear about this cable being an atypical interconnect for this purpose. I then go on to even give its frequency response which by the way, was a more severe case at 600 ohms vs 75 required for SPDIF. If you missed all of this and I explained it again here with a link to the original thread, surely the right reaction is not to call my ethics into question and claim incompetence on my part.

Even though this cable is atypical, it did make an important point which was missed in your sufficiency test: that hearing audio is not the same as conveying all the data correctly to the other side. Timing matters. In my case, that low bandwidth cable still produced audio. But clearly induced jitter and distortion into the audio stream. You needed a proper instrument to see that and not an ad-hoc test of hearing audio as I showed.

Same happens by the way with very long cables which I assumed OP was asking about in this thread. Indeed, as I explain my WSR article on jitter http://www.madronadigital.com/Library/DigitalAudioJitter.html, the Audio Engineering Society recommendation for digital audio has the same analysis. Here is the graph from that as quoted from my article:



Are you going to call them incompetent for showing such degraded situations as to elucidate the point that sample timing is important and can get degraded?

Timing matters? Is it because it makes audible difference in this case? This is audio section of the forum so it's only a proper question. If you dodge such question, that means it's not audible.

I thought it was generally accepted that there is a level of jitter that is audible. Part of the reason that at least high end studios run al the digital off a single clock . . . to keep the digital timing consistent. Like any other signal sdistortion, of course, there are levels below which timing problems are inaudible. But I admit I haven't studied audibility studies in detail. Just wanted to know enough to be sure my decidedely not high end (Yamaha DSP Factory for you old timers) recording system was likely to be clean enough that any problems weren't digitally induced.

Jitter becomes audible when it is large enough and impacts the clock applied to the DAC. Many systems recover the clock from the digital bit stream and that is what clocks the DAC. Any jitter on the bit stream is translated to the audio signal in that case. Cables degrade bandwidth, long cables more so, and that can cause intersymbol interference (ISI) or signal-dependent (determistic) jitter, again appearing in the audio output. The eyes from the AES article appear to exhibit ISI.

This is all true. However, I'm compelled to expand on one point: This is not as common as it once was. When a DSP is involved, the data is almost always re-clocked, with the DAC being driven from the oscillator that drives the DSP. We used to use two-stage PLLs to get a synchronized, yet stable clock to the DAC, but today almost all audio DSPs have a hardware asynchronous-sample-rate-converter (ASRC) to filter the data to the DAC. This allows the recovered incoming clock from the bit-stream to have any amount of jitter, and even allows the incoming frequency to drift, without affecting the clock to the DAC.

The above seems to be headed towards a big misapprehension. Yes, if there is not a separate clock line, then the receiving equipment has no choice but to regenerate a clock based on some reference. Whether we call that "recover the clock from the digital bit stream" is a matter of word meanings, not the limits of technology.

It is surely true that the presence of timing errors in a digital bit stream is no excuse for audible jitter. One of the quality attributes of a DAC is its ability to reconstruct a faithful analog signal from the flakiest input signal possible.

That's the misapprehension. Any jitter on the bit stream should never be translated into the audio signal in that case. It is the responsibility of the DAC to recover clean audio from jittery bitstreams. The means for doing this well has been well known for at least 40-50 years. I know this for sure because in the late 1960s I personally maintained and serviced IBM computer tape drives that took highly jittery signals from tape heads and turned them into highly accurate streams of digital data, both in terms of data accuracy and also timing accuracy. This was the in the days of discrete transistor logic. There were several rows of circuit cards in a card frame that accomplished this. I could put a scope probe on the output of the tape head and see the highly jittered signal from the tape head, and I could move the probe to someplace else and see beautifully clocked accurate data.

So, has taking the jitter out of bitstreams become lost art since the 1960s? Some people would seem to want to have you think so when they rant and rave about audible jitter due to interconnecting cables. Twenty years after my ca. 1960s days with IBM (1983) I probed around in the circuitry of the first audio CD players. Again, I saw a highly jittery signal emerging from the phototransistor array in the first CD players, and then I moved my oscilloscope probe to several other places where I saw pristinely clocked and accurate digtial data and finally I saw audio signals on the output terminals that lacked audible jitter.

So, has taking the jitter out of bitstreams become lost art since the 1980s? Some people would still seem to want to have you think so when they rant and rave about audible jitter due to interconnecting cables. In 2002 some twenty years after my first experiences probing around in the first audio CD players I did some experiments wtih some common mid-fi surround processors. Since jittery digital signals were becoming rare, I figured out how to make them. Again I was able to put my oscilloscope probe on a highly jittery digital signal that I applied to the input of a mid-fi surround processor, essentially the same as was built into the AVRs of the the day. Again, I saw audio signals on the output terminals that lacked audible jitter.

The bottom line is that there is one word of with many synonyns that describes digital audio gear that can't remove audible jitter from jittery digital audio signals: Defective.

If someone tries to convince you of your need to feed the equipment he sold you via special cables to avoid audible jitter, he's implicitly telling you that the equipment he sold you is defective. It is as simple as that!

Hmmm... Thanks Mark, I have not stayed in close touch with audio DAC clocking circuits. A few years ago, few AVRs reclocked the DAC, but that may well have changed. I do understand clocking schemes, though it is not obvious from my post. My work has focused on much higher-speed systems so I do not have much experience with audio DAC systems.

Arny, reclocking requires extra circuitry and often a buffer to isolate the incoming and outgoing clocks. For a continuous data stream, assuming the clocks are not exactly 100% aligned, you'd need an infinite buffer. As I mentioned above, my work includes DACs, but at much higher data rates (few hundred MHz to 10 GHz and up, full custom IC designs). When I speak of a DAC, I mean the actual DAC; it is up to the system to provide a clean clock (which was sometimes also part of my job). In the audio world, a "DAC" often means a whole lot more than just the DAC core itself, and I think that is where I trip myself up in speaking with you and others about audio DACs. In high-speed data streams like PCIe and SAS, my current work, there are all sorts of schemes to prevent losing synch, including the means to resend packets. Audio bit streams are one-way, something I have to keep reminding myself.

I agree that any good PLL/DLL/similar clock recovery circuit can provide a clean clock, but in general that does not preclude a cycle slip now and then. Audible? I doubt it, but I was speaking in general. I have discovered arguing audibility is a waste; someone will always claim my ears/audio system/power/air quality/whatever is simply not good enough to hear what they hear.

I am on record that random jitter is inaudible to me unless something is really hosed; I am less certain about deterministic jitter but have not seen test results that would provide any conclusions. I ran some simulations on digital cables over at WBF and it would take an extremely bad cable and/or very high jitter to become audible, at least in the presence of music. I generally shy away from “do you hear what I hear” arguments due to the above.

As for pulling signals from noise, in the commercial world tapes come to mind but modern disk drives take the prize for me. Looking at what comes off the head and gets turned into clean 1’s and 0’s is just amazing. There is some serious signal processing going on, as well as some really good analog design (my background is analog/mixed-signal). And of course, lots of error correction and handshaking, etc.

Is this not the era of a million transitors for a dollar, more or less?

There are two common methods around that. One is to send feedback to the source when it has sent too much or too little data given the size of the local buffer. The other is to presume that the reason why the local clock is on the verge of overrunning or underrunning the local buffer is that the local clock is wrong, and adjust it. Both methods have mainstream implementations for a reasonable price.

Already covered above.

Early in life I figured out the advantages that accrue to the most aggressive liars or fantastic optimists unless people call them on their wild claims. That is one reason why I invented ABX.

I stand by my claim that any normal RCA wire of a normal length is fine for digital audio. Why would you even do a test using wire with a built-in filter if not to make an irrelevant point? And you didn't bold and italicize that text in your original posts.

--Ethan

Intellectual dishonesty.

As I have repeatedly noted Ethan, that test was for another purpose. It just happened that it also fit to counter the statement you made. And provided useful information to OP here:
At the risk of getting beat up again for bolding something that originally wasn't , we were being asked about signal degradation in long cables. So your point regarding "normal length" is not appropriate to this thread. As cables get long their bandwidth is reduced. And performance is degraded in ways that your casual test (i.e. hearing sound) does not demonstrate. Same implication was made in the WBF thread and it is important that we don't ignore how these systems really work.

As to me bolding the test scenario originally, I fully capitalized what I typed to make sure the point was not missed: "(NORMAL audio, NOT S/PDIF)". That is an accepted method of highlighting things online. Further, I went on to even show you the frequency response graph of the low bandwidth cable. Surely that was not easy to miss, was it?

All of this said, as I interact with you in the future I will try to do better and emphasize key points further.

Now that I know your MO, it might be best if you didn't interact with me at all.

--Ethan