yeah Audiofreak32 seems to rub people the wrong way a lot & he's done that in one too many threads. He (it does not look like it's a 'she') indulges himself in this audio forum but provides no useful information (which the very essence of being involved with any audio forum - if you have some info, share it with others so that as many of the audio community will be better off. Long-term it will make for a better educated audio community & will raise the bar for manuf & listeners alike). But Audiofreak32 is far too obstinate to get that concept....
I'm not sure that I can contribute much here but here is an attempt:
From a very detailed engineering article I was reading (it's an old article in that it's 10+ yrs old but it clearly shows some of the hurdles that exist in the USB format as used for data transfer in an audio application. just for this sake, this article is useful) here is a short cut & paste:
"There are four USB transmission modes (please see Table 1). The two of those that are used for sending large quantities of data are (1) Isochronous Mode - A fixed number of packets is guaranteed to be sent and received. This mode is used with multimedia data such as images and audio. (2) Bulk Mode - A fixed quantity of data is sent at one time. If for some reason some of the data, is lost it is resent.
For data storage or printer applications the bulk mode is best because speed is of utmost importance and, through retransmission, data errors will be eliminated. But for audio data, real-time transfer is even more important than occasional missing data. (Noise is more tolerable than interruptions in the data. Of course pops and clicks are intolerable, but even more unpleasant is an intermittence of the data.) In this case, the isochronous mode is used. In other words, a real-time transmission scheme, with no re-sending of packets, is used for audio data, which streams from the PC in an RS-232-C-like manner.
USB is Clockless, Differential, Serial Transmission
It is not our intent to fully discuss the USB specification here. (Please refer to sister publication, Interface, March 2000.) USB 1.1 is a 12 Mbps bi-directional, serial bus, which is connected with 4 conductors....
Two of those conductors are power (VBUS) and ground (GND). Information is transferred through the other two: 1) D+ 2) D- Since there are only two data lines, only four states can be used for data transmission.
......
It follows that there is no explicit clock on the USB cable (this compounds the problem). Rather, the signal is restored based upon the intervals between edges of the data. In this type of digital communication, if the sender uses a perfect clock to create the signal, and the receiver uses a perfect clock to interpret the data, the original data can be reconstructed. Since NRZI reconstruction is possible if there is a clock that is four times the bit rate, it can be accomplished if both the sender and receiver both have 48 MHz clocks (the transmission rate is 4 times 12 Mbps).
However, when viewing this from the standpoint of an audio device, the very fact that the sender and receiver both have local clocks becomes a stumbling block.
The Evil of Clocklessness
The fact that there is no clock line within the USB cable leads to a thinner cable which is an advantage. But, no matter how good the crystal oscillators are at the send and receive ends, there will always be some difference between the two. For example, if the sender is sending audio data at a rate of 48.001 MHz and the receiver is receiving at 47.999 MHz, the receiver is reconstructing data slightly slower than the transmission rate. When a large quantity of audio data is sent under these conditions, the buffer will soon overflow, resulting in lost data
On the other hand, if the receiver is running faster, an underflow will occur resulting in a discontinuity in the audio data. In a CD player, angular control can be used to control the motor such that it will synchronize with the playback data rate. But the USB receiver cannot control the sender. The resulting missing data can be digitally compensated (using a smoothing filter, please see Figure 6), but our company's development philosophy does not allow for such deception! (As an aside, there is no problem at all if the data is reconstructed with the receiver's clock after it has all been sent.)
.....
A FIFO is Used to Deal with Packets that are not in Order
USB sends audio data packets on 1 ms intervals. Since, as mentioned previously, pauses in the audio cannot be tolerated, audio playback begins when the first packet arrives, and the next packet must arrive before all of the data in the previous packet has been played. Although we are discussing audio packets in particular, it is possible for the order of packets to be disrupted by other USB packets. In other words, a FIFO large enough to hold at least two packets is required to deal with the possible change of order.
In the case of dealing with 48 kHz, 16-bit stereo data, the buffer capacity must be at least 48 x 16 x 2 x 2 = 3,072 bytes......
USB Clock Error Uses up the FIFO!
On the other hand, the USB specification allows for clock frequency error of 500 ppm. This is an easy-to-accomplish specification for a crystal oscillator and makes the design of the USB circuitry rather easy. However, this is an allowance for an error between the send and receive clocks, and poses a problem for audio.
In this case, the read and write clocks for the FIFO are different. As the 500 ppm error accumulates, the 1 packet buffer margin will be completely used up in 2,000 packets. Since 1 packet is 1 ms, 2,000 packets works out to 2 seconds. If one packet is lost and the device jumps to the next, a popping sound will be heard........
The Terrors of the Isochronous Mode
We still have a problem. It is a problem with a USB mode: in the adaptive isochronous audio transmission mode, the receiver has to determine the bit rate. This means that the bit rate is unknown prior to the time the data arrives.
The bit rate cannot be known prior to actually observing the packet.
Another terror of USB is that, according to the specification, it would not be unusual for the bit rate to change when the operating system is busy. Since the packets arrive on 1 kHz intervals, the PLL must lock within 1ms. In most PLLs, if we say that 1 kHz fluctuations are clearly audible and decrease the gain, we cannot track! Terror of terrors, we have just bumped into a brick wall. Upon doing some investigation, we were actually able to observe fluctuations in the audio frequency characteristics of one company's USB-DAC. Upon listening this could be detected as a disruption in the rhythm of the music. In reality, fluctuations in the time domain will probably result in an unpleasant listening experience. This is probably because they are delaying the lock-up time in order to reduce the jitter distortion.
Also, for isochronous USB data, a buffer is necessary for the time between the beginning of the packet until PLL lock, so the PLL lock-up time is reflected directly in the chip cost. The more audio quality is pursued, the longer the necessary buffer and the longer the time lag when playback begins.
.............."
there's a lot more to this article that was intended for people skilled in the art of USB interface, PLL (phase locked-loop) & delta-sigma D/A design. IOW, it's an article written for an analog/mixed-signal engineer. Hence only relevant bits & pieces pertaining to why the USB interface provides a (serious) challenge in hi-end audio data xfer were cut & pasted.
You can read the entire article at your own peril here:
http://eetimes.com/design/audio-design/4009467/The-D-A-diaries-A-personal-memoir-of-engineering-heartache-and-triumph
(BTW, there'll be a test afterwards to check comprehension & understanding. LOL! :-D)
Hfisher3380, hope that this helps....
I'm not sure that I can contribute much here but here is an attempt:
From a very detailed engineering article I was reading (it's an old article in that it's 10+ yrs old but it clearly shows some of the hurdles that exist in the USB format as used for data transfer in an audio application. just for this sake, this article is useful) here is a short cut & paste:
"There are four USB transmission modes (please see Table 1). The two of those that are used for sending large quantities of data are (1) Isochronous Mode - A fixed number of packets is guaranteed to be sent and received. This mode is used with multimedia data such as images and audio. (2) Bulk Mode - A fixed quantity of data is sent at one time. If for some reason some of the data, is lost it is resent.
For data storage or printer applications the bulk mode is best because speed is of utmost importance and, through retransmission, data errors will be eliminated. But for audio data, real-time transfer is even more important than occasional missing data. (Noise is more tolerable than interruptions in the data. Of course pops and clicks are intolerable, but even more unpleasant is an intermittence of the data.) In this case, the isochronous mode is used. In other words, a real-time transmission scheme, with no re-sending of packets, is used for audio data, which streams from the PC in an RS-232-C-like manner.
USB is Clockless, Differential, Serial Transmission
It is not our intent to fully discuss the USB specification here. (Please refer to sister publication, Interface, March 2000.) USB 1.1 is a 12 Mbps bi-directional, serial bus, which is connected with 4 conductors....
Two of those conductors are power (VBUS) and ground (GND). Information is transferred through the other two: 1) D+ 2) D- Since there are only two data lines, only four states can be used for data transmission.
......
It follows that there is no explicit clock on the USB cable (this compounds the problem). Rather, the signal is restored based upon the intervals between edges of the data. In this type of digital communication, if the sender uses a perfect clock to create the signal, and the receiver uses a perfect clock to interpret the data, the original data can be reconstructed. Since NRZI reconstruction is possible if there is a clock that is four times the bit rate, it can be accomplished if both the sender and receiver both have 48 MHz clocks (the transmission rate is 4 times 12 Mbps).
However, when viewing this from the standpoint of an audio device, the very fact that the sender and receiver both have local clocks becomes a stumbling block.
The Evil of Clocklessness
The fact that there is no clock line within the USB cable leads to a thinner cable which is an advantage. But, no matter how good the crystal oscillators are at the send and receive ends, there will always be some difference between the two. For example, if the sender is sending audio data at a rate of 48.001 MHz and the receiver is receiving at 47.999 MHz, the receiver is reconstructing data slightly slower than the transmission rate. When a large quantity of audio data is sent under these conditions, the buffer will soon overflow, resulting in lost data
On the other hand, if the receiver is running faster, an underflow will occur resulting in a discontinuity in the audio data. In a CD player, angular control can be used to control the motor such that it will synchronize with the playback data rate. But the USB receiver cannot control the sender. The resulting missing data can be digitally compensated (using a smoothing filter, please see Figure 6), but our company's development philosophy does not allow for such deception! (As an aside, there is no problem at all if the data is reconstructed with the receiver's clock after it has all been sent.)
.....
A FIFO is Used to Deal with Packets that are not in Order
USB sends audio data packets on 1 ms intervals. Since, as mentioned previously, pauses in the audio cannot be tolerated, audio playback begins when the first packet arrives, and the next packet must arrive before all of the data in the previous packet has been played. Although we are discussing audio packets in particular, it is possible for the order of packets to be disrupted by other USB packets. In other words, a FIFO large enough to hold at least two packets is required to deal with the possible change of order.
In the case of dealing with 48 kHz, 16-bit stereo data, the buffer capacity must be at least 48 x 16 x 2 x 2 = 3,072 bytes......
USB Clock Error Uses up the FIFO!
On the other hand, the USB specification allows for clock frequency error of 500 ppm. This is an easy-to-accomplish specification for a crystal oscillator and makes the design of the USB circuitry rather easy. However, this is an allowance for an error between the send and receive clocks, and poses a problem for audio.
In this case, the read and write clocks for the FIFO are different. As the 500 ppm error accumulates, the 1 packet buffer margin will be completely used up in 2,000 packets. Since 1 packet is 1 ms, 2,000 packets works out to 2 seconds. If one packet is lost and the device jumps to the next, a popping sound will be heard........
The Terrors of the Isochronous Mode
We still have a problem. It is a problem with a USB mode: in the adaptive isochronous audio transmission mode, the receiver has to determine the bit rate. This means that the bit rate is unknown prior to the time the data arrives.
The bit rate cannot be known prior to actually observing the packet.
Another terror of USB is that, according to the specification, it would not be unusual for the bit rate to change when the operating system is busy. Since the packets arrive on 1 kHz intervals, the PLL must lock within 1ms. In most PLLs, if we say that 1 kHz fluctuations are clearly audible and decrease the gain, we cannot track! Terror of terrors, we have just bumped into a brick wall. Upon doing some investigation, we were actually able to observe fluctuations in the audio frequency characteristics of one company's USB-DAC. Upon listening this could be detected as a disruption in the rhythm of the music. In reality, fluctuations in the time domain will probably result in an unpleasant listening experience. This is probably because they are delaying the lock-up time in order to reduce the jitter distortion.
Also, for isochronous USB data, a buffer is necessary for the time between the beginning of the packet until PLL lock, so the PLL lock-up time is reflected directly in the chip cost. The more audio quality is pursued, the longer the necessary buffer and the longer the time lag when playback begins.
.............."
there's a lot more to this article that was intended for people skilled in the art of USB interface, PLL (phase locked-loop) & delta-sigma D/A design. IOW, it's an article written for an analog/mixed-signal engineer. Hence only relevant bits & pieces pertaining to why the USB interface provides a (serious) challenge in hi-end audio data xfer were cut & pasted.
You can read the entire article at your own peril here:
http://eetimes.com/design/audio-design/4009467/The-D-A-diaries-A-personal-memoir-of-engineering-heartache-and-triumph
(BTW, there'll be a test afterwards to check comprehension & understanding. LOL! :-D)
Hfisher3380, hope that this helps....