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).
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.
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
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
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.
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.
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.
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.
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.
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.
USB controller uses the same DMA like any other advanced PCI device. Where did you get such nonsense?
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.
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!
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!
Attachments
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
It's in the USB specs. I'll admit that some docs have been deleted since USB 3 came out...
Well, that's what I said, no? Other interfaces can stream audio without interrupting the CPU.
For instance, you can read RAM contents over FW without CPU or OS intervention. Tou can't read RAM through USB without OS AND CPU intervention.
IMO you just did not understand that. The endpoints themselves cannot access over DMA, of course, but the usb controller which is responsible for transfering the data to your CPU is using DMA.
Do you actually know how USB operates on the OS level? Did you take a look at e.g. linux core usb and audio usb drivers?
Do you actually know how IRQ-assisted DMA transfer operates? Any interface works on its own while the CPU writes/reads fresh data. Every time IRQ is thrown the CPU is notified what part of RAM the device just finished (reading/writing). The driver configures the device (by writing to the chip registers) at what points the IRQ should be thrown.
For PCI the CPU writes raw samples to RAM, e.g. S32_LE format. For USB the individual USB drivers (e.g. audio usb driver) provide data to the core USB driver (driver = sw = cpu) which formats usb frames based on the individual stream data a stores them to RAM. For the USB controller to read them over DMA a transmit to the hooked devices. The only difference is the extra work with preparing the frames but that is just copying data and adding frame headers with corresponding information.
If you really did your homework and looked at e.g. Intel UHCI datasheet ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf , you would know that UHCI controller has a list of up to 1024 memory locations where the frame data are stored and reads them in a cycle (via DMA, how else) - page 4 of that datasheet. If the CPU prepares all 1024 frames at once, it can go to sleep and the DMA controller will be busy for 1024 ms transfering those frames. E.g. 1second of audio in adaptive mode. And it does work, you can check by playing with linux usb audio driver. I actually did that http://www.diyaudio.com/forums/pc-based/93315-linux-audio-way-go-92.html#post1719044 and USB adaptive audio allowed fewer CPU wakeups per second than regular PCI cards.
The difference with asynchronous mode is that CPU cannot prepare many frames in advance since it must take into account the feedback control messages "slow down/speed up", reducing/increasing number of samples in newly prepared frames (for adaptive mode that number is constant). Yet the change does not have to occur immediately, giving still the CPU room to prepare several frames at once.
Please learn the facts first.
Last edited:
Well, there you go...
I don't have to look at the Linux model (which has been wrong for many years). If i probe memory over FW or PCI, I can read it. Can't do that over USB. And the fact that talented Linux devs got it wrong for years, proves what a mess it is.
Besides, it's a hardware difference more than software.
Qué?
Quite frankly, I have given up on Linux and audio. It's the one thing on Linux that doens't seem to work.
I used to know the facts. Then came USB2 and things started changing. A large number of devices were released that didn't follow the rules; and the USB3 appeared and the rules vanished. And I do mean that literally.
For instance: once a power supply of 5V, 500 mA was expected from a USB port. I am pretty sure this once was a rule. Gone. There's no document left on the USB association's website that explains what kind of power to expect. It's no longer mandatory.
And frankly, I no longer care about those rules. USB will go the way of the dinosaurs because it has become unreliable since Ivy Bridge.
I deal with those problems on a daily basis. And believe me, lots of audio driver developers are pulling hair over USB.
Sory... Have to go...
Surely there are two separate issues here: what performance (e.g. in terms of timing) does any compliant USB port provide, how does it do it? Then the third issue is whether software correctly exploits the USB port to provide the full service which a compliant USB port ought to be able to provide. Someone writing a driver with data integrity in mind (the usual IT requirement) could conceivably miss some of the timing issues, regarding them as unimportant. There certainly seem to be rumours that some Linux USB drivers are better at handling audio than others.
The key question is - how can a software influence hardware-based timing. No matter whether PCI or USB, both clocks are HW generated. I had a lengthy discussion on that topic How to set up MPD on Ubuntu 11.04 - Page 10 and noone presented any realistic scenario how a software could achieve that.
In USB the effect could be varying amount of samples in each frame, forcing the clock-reconstruction PLL to accomodate the fluctuation. I did capture USB data in linux to check that and can confirm that for USB adaptive the number of samples each frame (1ms) is always constant - as good as it can get.
A bug in usb power management. If you want to see bugs in linux usb audio, just follow the alsa-devel mailing list. But what relevance does it have to your DMA claim? Something like "Linux is so buggy that it even uses DMA for USB"? I have bad news for you - all other OSes have the same "bug". They have to if they want to run their hardware which just happens to work that way.
What a pointless discussion...
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.