No Problem.
Quote:
^Thanks for explaining that
EDIT: Do you think it might be possible that when we are talking about DAC designs for example USB DAC chip with on-chip USB receiver that the level of noise either picked up or transmitted by the cable could find it's way past the filtering stage if there is no galvanic isolation. In the case of digital transports such as the one I am using noise still doesn't go much distance toward suggesting a possible mechanism for the influence of USB cables on a DAC.
Past the filtering stage is unlikely. Noise in digital signal transmission usually does not affect its interpretation, unless it is causing swings in the voltage level. Hence, any data, if corrupted by such noise, will be used as such by the receiver if not checked for error.
Quote:
If I am to understand Liamstrain posted in theory noise should not really affect the performance of an asynchronous USB receiver as there are large enough tolerances built in that there should not be any packet drops? I guess though one would need to take into consideration the range of tolerances from the USB standard for the cable, to the USB standard for the USB controller, the level of noise on motherboard power supplies for the USB ports (or just measure the USB signal with an oscilloscope.) "0.0 to 0.3 volts for low (0) and 2.8 to 3.6 volts for high (1) in full-bandwidth" does seem like quite a large tolerance and that if devices can tolerate up to 10% of these numbers in noise it would certainly seem pretty hard for the USB input to exceed these tolerances. I am probably at risk of laboring over this point excessively but still I am curious.
Basically, the concept is this. All USB transfer types (Control, Bulk, Interrupt) except Isochronous, use a Token Packet -> Data Packet -> Handshake Packet during transfers.
Token packets transmit the state of the host/device (ready/not ready), Data packets carry data, and Handshake packets transmit a final response from host/device (acknowledge/negative acknowledge/stall) to end a transaction.
Isochronous transfers do not have the handshake packets, which means, the device will not acknowledge the receipt of data packets. Since timely transfer of data is more important for audio/video streaming, the host (your PC) may choose to drop certain packets if its not able to meet the bandwidth requirement (maybe busy doing other stuff, or the bus is too busy with other data).
However, this does not mean there's no possibility of error checking. If a CRC is transmitted along with the packet, the device can perform an error check on its own. Whether that is of consequence is another issue. Since the device won't re-request the frame from the host, it can just drop the packet.
So as you said, the tolerance for voltage is pretty high, so usually, the question is whether all packets are transferred reliably by the host, received by the device and not dropped. Windows can use ASIO for example, to minimize latency and give direct access to the sound card, bypassing the kernel mixer.