Zd542, I have seen dual headed USB cables with one connector dedicated to power and the other to signal. But I am not sure about which thread you mean. I searched "Dual Headed USB hookup" in Audiodon and nothing came up. |
Of course, you do. My question was, "Can you explain it"? |
I never said cables don't matter. I said transmission should be error-free over a short USB cable. I would like to hear the reasons why you disagree. Your answer should be more substantiated than "I heard it was better". Not to say that your experience doesn't count. Of course, it does. But my question was "Can you explain it"? |
There are two reasons for the question: 1) there could be something I don't know, like some manufacturing issues with USB cables (but even then I doubt the solution would necessarily be expensive) and 2) spread the word. |
Contrary to what you have assumed, I don't want to hear an answer that supports mine. I want to hear an answer that challenges mine. |
"Impedance of the USB cable is irrelevant."
Over a long length cable, distributed capacitance will close the eye enough to to cause bit errors. |
At least my post is seeking a discussion which has value, even if you don't think so. On the other hand your post has no value. Troll. |
|
I have listened to my DAC with the vanilla cable that came with the DAC and without cables (just a thumb drive). No difference. That is how Asynchronous USB DACs should behave by design.
My question wasn't about the cable's effects on SQ. It was about failure: At what distance does a vanilla USB cable start to fail? I'm sure the answer varies with drivers and date rate. For example, we know that PCM should travel farther than DSD.
The reason I am asking is because I am considering a music server plus DSD DAC (ExaSound E22 or PS audio DirectStream) and would like to a general idea of how far away I can place the server from the DAC.
I have asked manufacturers this question. Still, hearing your specific experiences may be helpful. |
"I'm not sure how you came up with that. PCM data can be transferred in more than 1 way. 75ohm coax, Toslink, 110ohm balanced, AT&T ST fibre optic, I2S, USB....."
Basic physics explains why faster data rates cannot travel as far as slower data rates. |
My OP asked about need not preference for expensive USB cables. This could have been posted more clearly. Need is about functionality. Preference is about whatever floats your boat including SQ, looks, durability, and reliability. But, I am glad that we are talking about both. Because if it comes down to bit errors (I think it does), what I first viewed as a preference may actually be a need. I can further elaborate on this by posing a question and then answering it.
If bits are either 1s or 0s, how can USB cables provide a gray scale in SQ?
Short answer:
Bit errors due to insufficient margins.
Long answer:
I believe digital audio has the misfortune of being a real-time application that uses designs intended for non-real-time applications. In real-time applications, there is one chance to get it right. Large margins are specified for all component designs in order to prevent bit errors. Typical USB applications (data transfer) are not real-time. They do not require large margins because bit errors are acceptable. You have the luxury to either retransmit until the received packet is error-free or you apply forward error correction to fix the error. We do not have this same luxury in audio. While music will flow with bit errors, those bit errors distort the analog wave shape (lower SQ).
Of course, isolation is also an issue. Al has an excellent post above that discusses isolation. But in this case, the cable solution is a bandage not the issue. Therefore, while I fully agree with you Al, I left this for another time.
My guess is that one USB cable may provide better SQ over another if it has better analog properties that prevent eye closure and transmit fewer errors. Having said that, what is good enough? Is it the cable that costs another $50 or $500? I think the cable industry intentionally does us a disservice of keeping us in the dark in order to sell into that ignorance. The test would be simple: Pick a nominal setup and test for data rate vs bit error rate. Then you pick an acceptable bit error rate (let's say your typical song is 4 minutes so you pick BER < 1 per 5 minutes) and select the least expensive cable that does not exceed that bit error rate. |
Thanks Sd542. I was originally thinking functionality only because bit errors should be zero in the audio range. But digging deeper, I realize that may not be true. Some USB cables may result in fewer errors than others. In which case, it's not only about functionality but also about SQ.
Cable manufactures aren't doing anything illegal. But I would call it unethical to mislead the customer for profit. |
Hi Kijanki, I agree with everything you said except for this one thing: "...jitter does not even apply here".
Just because the source clock isn't used inside the DAC doesn't mean that it has no effect. The DAC clocks data only after it reaches the DAC. The source clocks data up to that point. Source clock jitter combined with cable jitter may err a bit before it reaches the DAC.
For short cable runs, bit errors induced by the cable are unlikely. For long cable runs, bit errors are inevitable. Therefore, the longer the cable and more marginal the source, the more the cable matters for both function and SQ.
Of course, as you mention, a cable may also help SQ by isolating the signal from various noises. |
Here is a link showing a good USB eye vs bad eye.
http://www.embeddedstar.com/weblog/2009/06/07/industrial-usb/
Here is a USB chip vendor's failing eye diagram.
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/283089/987150
One eye is open. The other two eyes are closed without a long cable. The good eye doesn't need any help. Any cable will do. The bad eyes need all the help they can get. The cable is critical. Reality is that you aren't searching for that magic touch (whatever that means). You are searching for the cable that does the least harm. Silver will 'sound' better because it is faster. But silver won't sound any better for the open eye. |
Kijanki, Your point about checksums is interesting. Let's say that a packet is dropped. What would take the place of the dropped packet? Would it be that the contents of previous packet are duplicated? Dropped packets are problematic regarless of how they are manged. The only good solution is o resend the packet.
With a buffer large enough for several minutes of audio, there would be ample time to resend packets. Does USB audio comply fully to USB standard specifications? The answer to that question would go a long way. Thanks. |
Kijanki, If USB DACs use off-the-shelf USB chipsets (why not?), then they can detect errors and negotiate re-transmission. The bits should be error-free. |
Thanks for the link. I like it.
There are four transfer modes: control, interrupt, bulk, and isochronous. It seems that bulk transfer (as long as the buffer is large) is the way to go.
Interrupt and bulk data transfers conclude with a handshake packet to provide confirmation that the data was received, or request that it be re-sent if it was not. Delivery of this data is therefore guaranteed, even if the time taken to deliver it is not.
But there is no guaranteed access to the bus in bulk trasfer mode. If you want guaranteed access to the bus, then you must use isochronous mod.
"With isochronous data it is not possible to retry a failed transaction. Since only one slot is allocated to the pipe during each frame, resending the data would delay transmission of the succeeding data samples, upsetting the time element of the data delivery. Consequently no handshake packet is sent and the data must be accepted as is.
Bulk mode can be used for a dedicated music server because the bus is free. But isochronous mode is required for computers. Question is, do you have a choice? If not, you have to accept the default mode of the DAC, which is likely isochronous.
The answer to the question are bit errors recovered? and therefore "do cables matter?" is it depends on the transfer mode. |
Kijanki, I like the Airport Express implementation. I tried AE with both optical and analog outputs. I'm pretty sure that my Meridian G68 processor uses a FIFO buffer with synchronous clocking. Therefore, the AE jitter is transferred. In your case, the clocking is asynchronous and jitter transfer is zero. But even in your case, AE noise can enter the DAC through the analog (but not the optical) cable.
Getting back to my OP about functionality vs SQ. I just received an email from George at ExaSound. Working with George is a pleasure. ExaSound DACs use error correction. Therefore, if it is functioning, it is optimal SQ. This is how it should be. DACs that don't implement error correction and use isochronous transfer mode, have to live with whatever transmission they receive. This is not how it should be. Hence my OP about functionality vs SQ. There are some gray areas, even for digital.
Noise is an additional factor. If a cable introduces source noise or EMI/RF to the DAC, then SQ could be significantly impacted. However, the difference between a bad and good cable is neither a steep nor expensive order. |
Optical is a good choice. Locate the source far away from the DAC, use an optical cable, and you have no noise. Use an asynchronous DAC with error correction and you have no jitter and no errors.
No noise, no jitter, no errors! What more could you ask for? Too bad optical is SPDIF. I guess there is one more thing to ask for: optical USB. |
Ozzy, what is your source and DAC? |
Bill, I hear you. But I am optimistic that we are getting to that point where they won't matter.
Optical has dispersion and the O/E converter generates noise. Therefore, you are technically correct that you can't eliminate noise altogether. But optical completely isolates noise from the source, as well as EMI and RFI that are otherwise introduced through an electrical cable.
All digital generate their own internal jitter, including asynchronous DACs. Therefore, you are technically correct that you can't eliminate jitter altogether. But you can completely isolate source jitter.
Bit errors will always exist. But they can be corrected.
In summary, we have ways to correct bit errors 100%, to completely isolate source noise, and to render jitter irrelevant. What we don't have is all three in one design ... yet.
Of course, this is limited to the DAC. Even if the DAC signal is pristine it can be contaminated by EMI/RFI upon leaving the DAC.
But that's a different world we are talking about. |
Ozzy, You're using the IFI usb power supply with the BDP-2 and DirectStream? |
