While it has no relevance to DMA, it has a lot of relevance to your state of mind.
While on a purely technical plane, from your point of view, you are certainly right, DMA access over USB is possible, you don't seem to be able to interpret the message.
I should have used "Isochronous transfers". But then, most people wouldn't understand what I was talking about. I am sorry for not being technically exact. And I'll add that, in theory, USB can also do isochronous transfers, only it's really not good at it, because while it's doing isochronous transfers there's no way to communicate with the interface. Hitch is very annoying with audio. And that is completely different from PCI and Firewire. In both those case, communication with the other end of the bus is possible.
OS is irrelevant, since this is a design/hardware issue.
Phew...
Hope I haven't produced any new inaccuracies
My heavy duty computer hardware knowledge is dated, but as i understand it DMA = Direct Memory Access is the ability of hardware to read/write memory independent of the CPU. AFAIK USB requires the CPU to access memory, it is a dumb interface.
I do, and have always considered USB for audio a compromise, largely come to market supremency because it is cheap & not near as much effort to implement as more suitable interfaces. I use Firewire.
dave
I do, and have always considered USB for audio a compromise, largely come to market supremency because it is cheap & not near as much effort to implement as more suitable interfaces. I use Firewire.
dave
Guys please take the few minutes it takes to learn how the overall USB chain operates and do not throw around random "wisdoms"
The chain has two parts:
A) Communication between the CPU and the USB controller. USB controller is no dumb device, it is a regular PCI controller, with configurable control registers, DMA access, IRQs, just like e.g. soundcard controller. A good example is VIA Vectro VT6212 - 4-port USB 2.0 Host Controller - VIA Technologies, Inc. & family used in add-on PCI USB controller cards. Some are produced for audiophiles too.
The CPU formats data the controller will transmit to its connected devices. It prepares data for several frames (1ms for USB1, 125us for USB2) at once.
About 90% (or so) of the frame payload is reserved for isochronous (time-continuous) transfers - audio, video. The driver (CPU) copies 1ms (or 125us) of audio samples for each connected soundcard and put them from the beginning of the frame. What is left is filled with data in the bulk mode (connected usb storage), if any.
The CPU stores the data to ram and the USB controller is told the memory location (by CPU writing to its registers). This DMA configuration is done once, and the memory locations are reused. I already gave a link to USB controller datasheet which describes that UHCI (ancient model) can remember up to 1024 frame locations - 1 second of data.
The USB controller reads/writes cyclically the configured memory locations and transmits the stored data to corresponding USB devices. Every time it reads the frame data, it sets a bit "have read" of that frame in RAM. If it hits a frame data with this bit set, it stops the loop - old data, nothing new to transfer.
When preparing the frames in advance, in some of them the driver sets a specific bit - "throw IRQ". Whenever the USB controller transfers a frame with such bit set, it throws an IRQ to tell the CPU "hey, I have just been here". Just like in any other DMA transfer - PCI soundcard controllers work just the same.
It is up to the CPU which frame will have such bit set. I pointed to my test of extreme load http://www.diyaudio.com/forums/pc-based/93315-linux-audio-way-go-92.html#post1719044 where the CPU set this bit in only 3 frames each second, resulting in the CPU being notified only 3 times a second!
B) Transfer of the data between the USB controller and the USB device. This runs continuously, timed by clocks generated in the USB controller. This transfer is dumb indeed but how is the CPU involved here? This is a different layer, just like I2S output of the soundcard controller, ethernet output of a network card, SATA output of a SATA controller, etc.
Guys, please learn, read the datasheets, read the specifications, read the incredible source of information - linux kernel source code, make your own picture and do not take for granted what someone told you without any factual support.
I know nothing, or very close, about the insides of hardware and software.
I was getting lost by the earlier posts, but having just read post425, it is starting to make sense.
To confirm:
The USB controller talks to the CPU.
The USB controller gets it's data from the addresses supplied by the CPU.
The addresses give the USB controller direct access to the data in those RAM addresses.
The wires linking USB outlet to USB device do not see any of this CPU to USB controller negotiation.
I was getting lost by the earlier posts, but having just read post425, it is starting to make sense.
To confirm:
The USB controller talks to the CPU.
The USB controller gets it's data from the addresses supplied by the CPU.
The addresses give the USB controller direct access to the data in those RAM addresses.
The wires linking USB outlet to USB device do not see any of this CPU to USB controller negotiation.
Guys, for the love of all that is good and holy, PLEASE don't be fooled into thinking that USB cable "quality" really makes a difference in terms of sound. This whole thread is making my eyes roll back into my head... for people saying "it's not a simple issue," no... it really is simple. Digital binary data is not communicated any differently through more expensive wiring. Just because it has to travel through a physical medium such as copper does NOT mean that it is "analog" information. The whole argument essentially boils down to packet loss. If there is 0% packet loss on the receiving end, then the signal has been perfectly transferred with NO change. The only change in sound that could really happen is happening at the ADC. If you do notice a difference in sound, it's most likely a placebo effect... either that or there's a broken wire internally causing packet loss. If that's the case, throw it out and buy another $5 cable. If you buy a $150 USB cable, you're a sucker, plain and simple.
What you say is correct if and only if the USB cable is carrying data only. The discussion (among those who believe in science) is whether this is true for USB audio. Those who disbelieve science carry on a different argument, about whether a cable can magically change bits of data in a way which improves the signal.
Exactly. And the two parts (A) CPU to RAM, B) RAM via DMA to USB controller and further to USB devices) run independent of each other (in terms of timing), asynchronously.
phofman gave a nice explanation on post 425...
I haven't read all the argument about DMA on usb etc, seems the misunderstanding is :
FireWire, PCI, etc, all implement "remote DMA", this means one end of the link (or node on the bus) has the means to access remotely the other end's memory, read/write blocks remotely, etc. When a PCI-Xpress graphic card needs to read a texture in the motherboard's RAM, it uses this mechanism to access the mainboard RAM (remote, at the other end of the link) and transfer the blocks without any CPU intervention, for example.
USB does not, data streams are sent as an ordered succession of packets, simply.
Obviously all smart chipsets (USB, FW, etc) all do DMA on their local memory, I guess the misunderstanding was about local DMA vs remote DMA through the link.
Note that remote DMA is completely useless for audio which is a stream transmission, so this is quite off topic. Unless your soundcard is, for example, a MIDI synthetizer, which stores its sample banks in the PC's memory, in this case it could use remote DMA, same thing as the textures for the PCIxpress graphics card.
That cable would have to be pretty smart to also spoof the block CRC as it messes with the bits...
I've taken apart some USB cables which had no shield, not even twisted pairs ! (of course the manufacturer was careful to use black cable so no-one notices)... and those cables didn't cause bit errors, so it's pretty robust ! The EMI must be horrendous, though...
To answer your question, I'd say the cable is carrying digital data (perfect and easy to check) plus some analog "information" (+5V with generous amount of 10Hz to GHz ripple on it, ground loop noise, EMI, etc) and of course the audio master clock (if the system uses adaptive mode, bleh).
I haven't read all the argument about DMA on usb etc, seems the misunderstanding is :
FireWire, PCI, etc, all implement "remote DMA", this means one end of the link (or node on the bus) has the means to access remotely the other end's memory, read/write blocks remotely, etc. When a PCI-Xpress graphic card needs to read a texture in the motherboard's RAM, it uses this mechanism to access the mainboard RAM (remote, at the other end of the link) and transfer the blocks without any CPU intervention, for example.
USB does not, data streams are sent as an ordered succession of packets, simply.
Obviously all smart chipsets (USB, FW, etc) all do DMA on their local memory, I guess the misunderstanding was about local DMA vs remote DMA through the link.
Note that remote DMA is completely useless for audio which is a stream transmission, so this is quite off topic. Unless your soundcard is, for example, a MIDI synthetizer, which stores its sample banks in the PC's memory, in this case it could use remote DMA, same thing as the textures for the PCIxpress graphics card.
That cable would have to be pretty smart to also spoof the block CRC as it messes with the bits...
I've taken apart some USB cables which had no shield, not even twisted pairs ! (of course the manufacturer was careful to use black cable so no-one notices)... and those cables didn't cause bit errors, so it's pretty robust ! The EMI must be horrendous, though...
To answer your question, I'd say the cable is carrying digital data (perfect and easy to check) plus some analog "information" (+5V with generous amount of 10Hz to GHz ripple on it, ground loop noise, EMI, etc) and of course the audio master clock (if the system uses adaptive mode, bleh).
Thanks for the write up, that indeed looks like the point.
For audio what counts is the local DMA which allows the division of work between the CPU and the USB controller.
Yeah, and you won't find any usb2 chipset without some form of DMA on its local memory. Simply because USB2 has ultra strict timing requirements...
When the master requests data from the slave, it has at most "BTT"=bus turnaround timeout (which is just a few bit times at 480Mbps) to send the data. So the data must be available and ready to be transmitted, waiting in some memory which is directly accessible by hardware, either an endpoint FIFO, or some pretty fast DMA. Usually, RAM has too unpredictable latency, the bus might be busy from some other device bursting etc, so you'll find a small, fast FIFO which contains the first chunks of the packet, primed and ready to be sent at once, and a DMA engine to keep the FIFO full.
On simpler devices you have only a small FIFO. For example on a small USB uC, the cpu would write a packet to the FIFO, prime the hardware for sending, and it actually gets sent when the PC request it.
Same thing when the Master sends data : either the device is ready to accept it, or it isn't, and the transfer is delayed to the next microframe, or in case of iso transfers, the packet is thrown away.
FYI streaming 8 channels of 24/192 data on a LPC4330 micro takes about 1% cpu, that's one IRQ at 8 kHz, grab packet, queue another buffer, and copy the whole buffer using the CPU to reverse the bit order... I wish the serial engines could accept data in the PC's bit-order but they don't... beh, 1% waste of cpu, could live with that...
When the master requests data from the slave, it has at most "BTT"=bus turnaround timeout (which is just a few bit times at 480Mbps) to send the data. So the data must be available and ready to be transmitted, waiting in some memory which is directly accessible by hardware, either an endpoint FIFO, or some pretty fast DMA. Usually, RAM has too unpredictable latency, the bus might be busy from some other device bursting etc, so you'll find a small, fast FIFO which contains the first chunks of the packet, primed and ready to be sent at once, and a DMA engine to keep the FIFO full.
On simpler devices you have only a small FIFO. For example on a small USB uC, the cpu would write a packet to the FIFO, prime the hardware for sending, and it actually gets sent when the PC request it.
Same thing when the Master sends data : either the device is ready to accept it, or it isn't, and the transfer is delayed to the next microframe, or in case of iso transfers, the packet is thrown away.
FYI streaming 8 channels of 24/192 data on a LPC4330 micro takes about 1% cpu, that's one IRQ at 8 kHz, grab packet, queue another buffer, and copy the whole buffer using the CPU to reverse the bit order... I wish the serial engines could accept data in the PC's bit-order but they don't... beh, 1% waste of cpu, could live with that...
There will be packet headers. Almost all communication channels involve some meta-data. That is what makes me wonder how weaker DACs get timing information from USB, as the audio data will certainly not be a continuous stream of data alone as it is with SPDIF. (Actually even that has meta-data but it is repeated for each pair of samples). I suppose a PLL is used to sync the output sample rate to the average of the input rate.
USB uses 1ms frames. So you get 1000 frames/s.
Each frame starts with a SOF, ie "start of frame" token (just a special kind of packet).
At high speed the 1 ms frame is divided into 8 microframes of 125 us. A SOF is sent at the start of each of these 8 microframes, each having the same frame number, which then increments every 1 ms frame.
Each microframe or frame contains packets. If there is not enough data to transmit to fill the frame, as is always the case with audio, the transmission will only take place during a small part of the frame length. Throughput is always 480Mbps (or 12M for full-speed). Of course all packets have headers, CRCs and all the usual stuff.
This timing is controlled from the host (ie, the PC). It is NOT subject to IRQ delays though (the USB hardware handles it directly), but it comes from a noisy XO somewhere on the mobo going through several chips, etc, so it is full of jitter, of course.
Adaptive DACs use a PLL synchronized to the SOF ticks to reconstruct an audio clock. Lots of cleanup work to do... rather useless IMHO since asynchronous eliminates the problem completely...
So the PLL cleans up HF jitter, but we are left with all the LF jitter from a cheap crystal clock on the motherboard (where the designer certainly didn't have audio in mind)? Given that, cables seem to be the least of the things to worry about. Why use a better string when the tin cans are all rusty and dented?
Yep. To complete the clear explanation by Peufeu, you can read this: http://www.thewelltemperedcomputer.com/Lib/Hitoshi Kondoh story.pdf
It's an history of the development of TI's first adaptive chipset.
If you mix clocks, you must have some sort of feedback to control the transmission rate. That is how the asynchronous mode operates. Or use asynchronous sample rate conversion (ASRC) to convert from the transmission clock domain to the DAC clock domain. I do not know if any USB DAC uses it, async mode makes more technical sense.
In adaptive mode (DAC clock generated by PLL) there is only one clock involved - the one in the USB controller, timing the transmission.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.