USB cable quality

[DF96]

Is the crystal clock in a USB interface designed for sufficiently low jitter?
Is the PLL designed to avoid adding jitter?
Is there sufficient buffering or DMA speed to maintain data under all conditions?

It is a while since I read it, but I seem to recall that the spec for USB audio is quite lax on timing issues (by hi-fi standards).

[phofman]

Originally Posted by DF96

Is the crystal clock in a USB interface designed for sufficiently low jitter?
Is the PLL designed to avoid adding jitter?
Is there sufficient buffering or DMA speed to maintain data under all conditions?

It is a while since I read it, but I seem to recall that the spec for USB audio is quite lax on timing issues (by hi-fi standards).

Hold on, in one post you talk about usb not being designed for any timing at all, only for data transmission, and compare it to realtime cpu processing, and now you ask about jitter/timing requirements by hifi standards. Quite a jump IMO. The PLL based recovery can provide very good results and does so as many professional audio devices use it. I am not saying its quality is top, no doubt a crystal clock provides much better results (hence the async node available since the beginning too) but it certainly is not the case that USB was not designed to deliver timing too.

I just want to make sure people do not understand that comparison with realtime processing as if perhaps USB clock was based on CPU processing. This fallacy (I am not saying you fall to this, you certainly know how USB operates) is fairly common about audiophiles. Unfortunately also among "audiophile players" developers who certainly should have known better if they ask money for their product.

The DMA - if the system is so loaded that DMA cannot hold up for USB, it cannot hold up for PCI either - it is the same bus, the same DMA controller where the communication occurs. Apart of that it has no effect on the USB bus clock, just like it does not have effect on clocks of PCI soundcards.

[phofman]

In my previous posts I kept mentioning "1kHz/1ms clock". I should have said the 12MHz clock. 1ms is of course just the frame size, no reason to base the clock recovery on that. My fault, sorry.

BTW, is there a fundamental difference between generating clocks by PLL from 24MHz crystal clock as in many PCI/e soundcards or by PLL from the 12MHz USB1 signals? I understand the signal by USB is not real clock, but a data stream at this timing, the jitter of the USB datastream is far larger, but I wonder what effect it has on the result. My practical experience with PLL development is exactly zero :-)

[davym]

I don't know that much about digital sound or USB capability, all I know is that I find an external clock helps with sound quality. If USB transfer is perfect, why would an external clock make any difference at all?

If digital USB sound is an exact science, then it's a first because as far as I can tell, there is no such thing as an exact science in any discipline, never has been, probably never will be.

[DF96]

Now I am confused. I have been told before that USB timing is simply not up to audio. Now I am being told that USB timing is (almost) good enough.

Could someone who really understands USB give us the definitive answer? This is a matter of fact, not opinion.

I can't claim any great USB knowledge. To me it just looks a bit like a watered-down version of Ethernet - which at one time I understood quite well as I was involved in developing device drivers for real-time systems.

[cyrano]

USB has no DMA. It always needs interrupts and processor intervention when it transfers data. That's the one big problem with it. As long as the CPU isn't doing anything special, it 'll work. Unfortunately, with most modern OSes, the CPU is always doing something. And it might even be doing something on one core while other cores are trying to play or record audio.

PCI, Firewire and Thunderbolt all have DMA and can read and write directly from RAM without processor intervention. As long as there is RAM available, there's no need to disrupt the stream. And the processor can move data from RAM to HD (or vice versa) when it sees fit.

Clocks can be regenerated. With a good PLL it's not that hard. But everything can grind to a stand still if the rest of the hardware can't keep up. And if you need more than 2 channels, or input and output with low latency simultaneously, you're better off with external clocks. That's why pro gear can use it's own internal clock, or be clocked by the most important device in the chain, or even an external clock generator. For only listening to music this is real overkill, but if you need to edit video and keep everything in sync, it can be a necessity if you have a big setup.

Also, there is a very annoying USB problem with Ivy Bridge that was worsened with Haskell. Lots of newer computers have problems dealing with USB audio.

USB3 is a PITA when it comes to audio. If you happen to have a really bad implementation of USB3, it 'll even kill wifi because it also operates at 2.4 GHz. Backwards compatibility with USB2 and USB1.1 is next to non existant when it comes to audio interfaces. The only manufacturer who has been able to present a working USB3 audio interface is RME. That's not really a surprise, as RME is also the only manufacturer that designs their own USB chips and writes the software for these. All the others use off-the-shelf stuff.

Jitter certainly isn't the biggest problem as you can cater for it in the audio interface. All setups I know do. It will be corrected up to a certain level.

[phofman]

Originally Posted by cyrano

USB has no DMA. It always needs interrupts and processor intervention when it transfers data. That's the one big problem with it. As long as the CPU isn't doing anything special, it 'll work. Unfortunately, with most modern OSes, the CPU is always doing something. And it might even be doing something on one core while other cores are trying to play or record audio.

USB controller uses the same DMA like any other advanced PCI device. Where did you get such nonsense?

Originally Posted by cyrano

PCI, Firewire and Thunderbolt all have DMA and can read and write directly from RAM without processor intervention. As long as there is RAM available, there's no need to disrupt the stream. And the processor can move data from RAM to HD (or vice versa) when it sees fit.

And the USB controller works in exactly the same way. Only for usb async it must act upon the received feedback relatively quickly and therefore must be notified by the IRQs every few msecs.

[phofman]

Originally Posted by phofman

Only for usb async it must act upon the received feedback relatively quickly and therefore must be notified by the IRQs every few msecs.

Of course not "it", but "the CPU".

[Nico Ras]

I have this Sound Blaster X-Fi titanium which is said to be "the card" for audiophools. Two weeks ago I bought this USB thing from China for $0.99 which included shipping.

When it comes to sound quality it out performs the X-Fi by an order of magnitude. On the bus installed sound card I can hear mouse movements and the hard drive access and software runs, the Chinese USB thing is King no noises just beautiful clear music!

[00940]

Originally Posted by davym

I don't know that much about digital sound or USB capability, all I know is that I find an external clock helps with sound quality. If USB transfer is perfect, why would an external clock make any difference at all?

Thing is, USB receiver chips are not only "receivers", they also often generate the master clock for the following digital chain.

The external clock will not/cannot markedly improve data transfer by itself. It can however help the PLL/clock generator section of your chipset.

You can find on the web measures made on the TI pcm2707 adaptive chipset as USB to I2S converter, showing varying performance in the generated clocks, depending on the power supply, layout, clock used, etc.

As a quick guideline, here are some measurements coming from G. Rankin, they're in line with what I've seen quoted by others :

PCM2706 3433ps
TAS1020B Adaptive mode changed every 4ms standard code: 2838ps
TAS1020B Adaptive my slow mode PLL code: 632ps
TAS1020B Async USB mode internal PLL: 482ps
TAS1020B Async USB mode OSC to MCLKi port generating I2S output: 73.2ps