Depends on the digital chain. If the USB chipset is in adaptive mode, that final clock is provided to the DAC IC by the PLL of the USB receiver, on the basis of the USB stream.
If the USB receiver is asynchronous, then that final clock is indeed inside the DAC box and can be as clean as we want. Hence the attraction of the asynchronous mode.
A third solution being to add an asrc in between the adaptive chipset and the DAC chipset, with a clock on the DAC side. Or, similarly, to add a secondary PLL.
edit: beaten to it by phofman
Yeah. If a DAC uses adaptive mode, there's going to be a LOT of work to clean up the crap. Like, use an ESS DAC in jitter cleaning mode, an ASRC, or some form of exotic PLL (XO controlled in small steps by a uC).
Who cares anyway - asynchronous mode solves the problem completely in an elegant manner and Does The Right Thing (in this case, each microframe, the DAC transmits the value of a sample counter to the PC, and the PC uses it to adjust the number of samples to send. Quite simple...
Only "problem" is if you want to have several USB DACs and synchronize them via USB, it is of course possible, one of them is gonna have to be clock master (asynchronous) and the others clock slaves (adaptive)... and then some form of word clock over coax or optical suddenly seems a lot more interesting than this mess !...
One interesting point is that when using asynchronous USB sound, then, of course, who is generating the frame clock for the video ?... There is no answer, so your movie might get out of lipsync... perhaps the OS can slave the video card to it, or not... Maybe you need a specific driver version ? Video players offer a "reclock" option which time-stretches the audio... to adapt it to the video card's frame rate.......... such a mess...
OK, no problem, let's use the HDMI video/audio out, and get back 20 years to the golden age of SPDIF, ie "oh yeah, my DAC is so transparent that it can resolve difference between digital sources" (ie, it's a POS with zero jitter rejection and EMI immunity)
Wondering why my Onkyo 905 AV receiver sounded so bad, I had a look at the schematics. The SPDIF travels in the HDMI cable, time-multiplexed with the video. No problem. Except the MCLK comes from PLLs in the video card... uh.
The HDMI chipset datasheet says something like "the chips has no PLL and performs no clock recovery, it outputs SPDIF clocked from a fractional digital divider fed from some clock input, please clean it before feeding it to DACs"... in other words, several tens of ns of jitter.
That's normal : since the HDMI signal may be forwarded to another port with some digital processing only, clean clock recovery isn't needed in the HDMI receiver chip, nor would it be of any use, since the place to put it is near the dac...
Anyway, they send this SPDIF thru a CSxxxx receiver which has a jitter rejection of zero, and then the I2S go thru over nine thousand connectors, some of them several times both ways since SPDIF/I2S muxing is distributed on several boards, each connector has 1 ground pin of course, I2S finally reaches the poor top of the line Burr Brown DACs, which are on a 2-layer board with no ground plane. The unfiltered DAC sharp output current pulses proceed to an unsuspecting herd of NE5532s. The sound which comes out of this very expensive piece of kit is awesomely bad. It fails as awesomely as (insert your favourite expensive government failure here). The amps are decent, though, with an external analog source...
Who cares anyway - asynchronous mode solves the problem completely in an elegant manner and Does The Right Thing (in this case, each microframe, the DAC transmits the value of a sample counter to the PC, and the PC uses it to adjust the number of samples to send. Quite simple...
Only "problem" is if you want to have several USB DACs and synchronize them via USB, it is of course possible, one of them is gonna have to be clock master (asynchronous) and the others clock slaves (adaptive)... and then some form of word clock over coax or optical suddenly seems a lot more interesting than this mess !...
One interesting point is that when using asynchronous USB sound, then, of course, who is generating the frame clock for the video ?... There is no answer, so your movie might get out of lipsync... perhaps the OS can slave the video card to it, or not... Maybe you need a specific driver version ? Video players offer a "reclock" option which time-stretches the audio... to adapt it to the video card's frame rate.......... such a mess...
OK, no problem, let's use the HDMI video/audio out, and get back 20 years to the golden age of SPDIF, ie "oh yeah, my DAC is so transparent that it can resolve difference between digital sources" (ie, it's a POS with zero jitter rejection and EMI immunity)
Wondering why my Onkyo 905 AV receiver sounded so bad, I had a look at the schematics. The SPDIF travels in the HDMI cable, time-multiplexed with the video. No problem. Except the MCLK comes from PLLs in the video card... uh.
The HDMI chipset datasheet says something like "the chips has no PLL and performs no clock recovery, it outputs SPDIF clocked from a fractional digital divider fed from some clock input, please clean it before feeding it to DACs"... in other words, several tens of ns of jitter.
That's normal : since the HDMI signal may be forwarded to another port with some digital processing only, clean clock recovery isn't needed in the HDMI receiver chip, nor would it be of any use, since the place to put it is near the dac...
Anyway, they send this SPDIF thru a CSxxxx receiver which has a jitter rejection of zero, and then the I2S go thru over nine thousand connectors, some of them several times both ways since SPDIF/I2S muxing is distributed on several boards, each connector has 1 ground pin of course, I2S finally reaches the poor top of the line Burr Brown DACs, which are on a 2-layer board with no ground plane. The unfiltered DAC sharp output current pulses proceed to an unsuspecting herd of NE5532s. The sound which comes out of this very expensive piece of kit is awesomely bad. It fails as awesomely as (insert your favourite expensive government failure here). The amps are decent, though, with an external analog source...
I do not think there is any difference between implementations of the audio clock in this regard. The player does not have access to the soundcard clock, the only timing information the player knows is the audio samples consumption rate. Async consumes the samples in the same way as adaptive does - at the rate of the corresponding audio clock.
AFAIK mplayer adapts the video playback to audio consumption to maintain the AVSync A strange A-V sync problem of MPlayer-1.0-pre5 ported on ARM920 - MPlayer development - ArchiveOrange
OK. DMA access was definitely the wrong acronym to use. It stems from the name "DMA attack over firewire".
Tell me, why can I R/W access the computer's ram from a Firewire port (or PCI or PCIe or TB) with just a few lines of code and not from USB?
PCI is largely irrelevant in this question, as there's no easy way to connect a cable to it.
I was told by audio interface driver developers that the reason USB is not ideal for audio is a hardware one and jumped to the conclusion that both things were related. Maybe not?
Tell me, why can I R/W access the computer's ram from a Firewire port (or PCI or PCIe or TB) with just a few lines of code and not from USB?
PCI is largely irrelevant in this question, as there's no easy way to connect a cable to it.
I was told by audio interface driver developers that the reason USB is not ideal for audio is a hardware one and jumped to the conclusion that both things were related. Maybe not?
Because IEEE1394 specifies and implements remote DMA...
Because USB does not
If you're worried about security, well, anyone who can plug stuff into the computer owns the computer anyway, so, who cares.
No relation (in my opinion)... audio is a data stream transfer, remote DMA is not useful for streams, rather for smart peripherals which need to access data in the PC's memory...
FireWire is pretty buried anyway...
This is/was one of the most interesting threads that I have read, thanks to Peufue and others doing a great job on this subject.
What I found is that my Creative Sound Blaster audiophool sound card performs worse than a $1 USB audio adapter from China or am I dreaming. On the sound card I can hear mouse movement, disc access, weird background noises, etc. USB is clean quiet and sounds great.Can anyone shed some light?
What I found is that my Creative Sound Blaster audiophool sound card performs worse than a $1 USB audio adapter from China or am I dreaming. On the sound card I can hear mouse movement, disc access, weird background noises, etc. USB is clean quiet and sounds great.Can anyone shed some light?
Because IEEE1394 specifies and implements remote DMA...
Because USB does not
OK, but that doesn't explain why.
Don't worry, I won't worry.
Are you really, really sure remote DMA isn't used for anything audio related? Not even for controlling clock, sending audio over ethernet...
It lives on in Thunderbolt. Strangely enough, all FW audio interfaces I've encountered work very well with a TB to FW adapter. Can't say that for USB interfaces. Hardly any of them are compatible with USB3.
>>Because USB does not
>OK, but that doesn't explain why.
You mean why USB doesn't spec remote DMA ?
The answer is simple... USB was designed from the start to target the cheapest, dumbest possible device. The whole protocol is designed to run on bottom-spec 8 bit micros or simple hardware. A USB device has need for very very small brains...
When you plug the device it enumerates, that means it sends a data block which contains a description of itself in a normalized format. Then, the driver in the PC is responsible for everything. For example, if the device has a Volume Knob, the enumeration will give it a control number, a description string, and some way for the driver to know what it is and what it's supposed to do (ie, the right ENUM integer value that the USB spec says it should have if you're using a class driver).
When the user turns the knob, the following happens :
PC - did something happen ? (this is called an INTERRUPT transfer, but it's actually polling from the PC, which ask this question N times/second)
Device - something happened to "Volume Knob" (actually, it's an integer control number)
PC - Give integer value of control "Volume Knob"
Device - responds with value
PC - Update sound volume of channel xxx with value xxx (PC also updates the volume slider in the GUI)
It kind of looks like a microcontroller talking on a I2C bus... really dumb, but very simple and effective.
The device never opens its mouth unless told to do so... there are no interrupts (just polling), the device has zero initiative, so it could not initiate a DMA transfer, for example...
That was control. Data transfer is implemented via endpoints which are, basically, just pipes. Each USB physical connection has a certain number of logical endpoints. When you push data into an endpoint on one side of the USB cable, it pops out of the same endpoint on the other side of the cable. That's about it, it's a data pipe... simple and efficient, and all you need to transfer a stream of audio samples...
FW is a much more complex and powerful protocol, which means the devices need to be much smarter, and more expensive, which is the reason why it's dead.
USB3 is somewhere between the two.
> Are you really, really sure remote DMA isn't used for anything audio related?
No idea if FW uses it, but I don't see what the use case would be for simple record/playback tasks... a data pipe is simpler and sufficient...
> Not even for controlling clock, sending audio over ethernet...
Ethernet doesn't have remote DMA either, it's a packetized network... you could implement remote DMA on top of it (using the right protocol) if you wanted to.
> What I found is that my Creative Sound Blaster audiophool sound card performs
> worse than a $1 USB audio adapter from China or am I dreaming. On the sound
> card I can hear mouse movement, disc access, weird background noises, etc.
> USB is clean quiet and sounds great.Can anyone shed some light?
Soundcard is inside the PC, which has a huge RF pollution, and is the worst place for analog circuits... USB adapter is outside, so it has the advantage.
But the most likely thing is that the soundcard feeds from the motherboard power bus, which will be modulated by the power supply demand of your harddisk, cpu, etc... all those power rails have DC to GHz noise in loads... feed that to opamps, they'll **** bricks... In the headphone jack of my laptop I can clearly hear the harddisk moving...
USB has an advantage again, since a $0.01 ferrite bead, cap, and if you're feeling exceptionally generous, a cheap LDO, will give you a power rail which is still crap, but probably 1000x less than what's inside the PC...
If you feel like hacking your soundcard, you could cut the power supply traces and feed it from an external DC supply, add some filtering...
>OK, but that doesn't explain why.
You mean why USB doesn't spec remote DMA ?
The answer is simple... USB was designed from the start to target the cheapest, dumbest possible device. The whole protocol is designed to run on bottom-spec 8 bit micros or simple hardware. A USB device has need for very very small brains...
When you plug the device it enumerates, that means it sends a data block which contains a description of itself in a normalized format. Then, the driver in the PC is responsible for everything. For example, if the device has a Volume Knob, the enumeration will give it a control number, a description string, and some way for the driver to know what it is and what it's supposed to do (ie, the right ENUM integer value that the USB spec says it should have if you're using a class driver).
When the user turns the knob, the following happens :
PC - did something happen ? (this is called an INTERRUPT transfer, but it's actually polling from the PC, which ask this question N times/second)
Device - something happened to "Volume Knob" (actually, it's an integer control number)
PC - Give integer value of control "Volume Knob"
Device - responds with value
PC - Update sound volume of channel xxx with value xxx (PC also updates the volume slider in the GUI)
It kind of looks like a microcontroller talking on a I2C bus... really dumb, but very simple and effective.
The device never opens its mouth unless told to do so... there are no interrupts (just polling), the device has zero initiative, so it could not initiate a DMA transfer, for example...
That was control. Data transfer is implemented via endpoints which are, basically, just pipes. Each USB physical connection has a certain number of logical endpoints. When you push data into an endpoint on one side of the USB cable, it pops out of the same endpoint on the other side of the cable. That's about it, it's a data pipe... simple and efficient, and all you need to transfer a stream of audio samples...
FW is a much more complex and powerful protocol, which means the devices need to be much smarter, and more expensive, which is the reason why it's dead.
USB3 is somewhere between the two.
> Are you really, really sure remote DMA isn't used for anything audio related?
No idea if FW uses it, but I don't see what the use case would be for simple record/playback tasks... a data pipe is simpler and sufficient...
> Not even for controlling clock, sending audio over ethernet...
Ethernet doesn't have remote DMA either, it's a packetized network... you could implement remote DMA on top of it (using the right protocol) if you wanted to.
> What I found is that my Creative Sound Blaster audiophool sound card performs
> worse than a $1 USB audio adapter from China or am I dreaming. On the sound
> card I can hear mouse movement, disc access, weird background noises, etc.
> USB is clean quiet and sounds great.Can anyone shed some light?
Soundcard is inside the PC, which has a huge RF pollution, and is the worst place for analog circuits... USB adapter is outside, so it has the advantage.
But the most likely thing is that the soundcard feeds from the motherboard power bus, which will be modulated by the power supply demand of your harddisk, cpu, etc... all those power rails have DC to GHz noise in loads... feed that to opamps, they'll **** bricks... In the headphone jack of my laptop I can clearly hear the harddisk moving...
USB has an advantage again, since a $0.01 ferrite bead, cap, and if you're feeling exceptionally generous, a cheap LDO, will give you a power rail which is still crap, but probably 1000x less than what's inside the PC...
If you feel like hacking your soundcard, you could cut the power supply traces and feed it from an external DC supply, add some filtering...
Last edited:
Peufue, thank you for your comment, I am sure you are absolutely correct. Regardless the Sound Card DAC specification of 24 bits and S/N of some 140 dB, when you mix all the crap back into the analog stream what is the point.
I now only use the little USB adapter, which honestly cost me $0.99 on eBay and shipping was included. This is fed to a headphone amp and a pair of HD800 Sennheisers.
The only problem that I found was that the manufacturer could not fit decoupling caps on the output, thus it is not suitable to plug headphones into directly.
Peufeu your explanations are very clear and simple to follow and you seem very knowledgeable on the subject - thank you.
I now only use the little USB adapter, which honestly cost me $0.99 on eBay and shipping was included. This is fed to a headphone amp and a pair of HD800 Sennheisers.
The only problem that I found was that the manufacturer could not fit decoupling caps on the output, thus it is not suitable to plug headphones into directly.
Peufeu your explanations are very clear and simple to follow and you seem very knowledgeable on the subject - thank you.
Last edited:
Honnestly, I don't buy it.
I've used quite a few internal soundcards (PCI and PCI-e) and never had an issue of the amplitude described by Nico Raes unless something is seriously wrong with either the soundcard, the motherboard or the power supply.
Integrated chipset used in laptop really cannot be used as a comparaison point.
I've used some pretty decent PCI soundcards too, those had a floppy drive power supply connector, probably didn't use the power from the mainboard... not too much noise problems with those, i guess it's all about wether or not the soundcard designers did their job properly...
what soundcard is it nico ?
what soundcard is it nico ?
So, you see the fact that USB seems to be a pretty primitive device as an advantage?
BTW I didn't mean ethernet over UTP, I was thinking about ethernet over Firewire.
I see both network and audio over Firewire completely outperforming USB. But you seem te believe USB is at an advantage because it is so primitive. Strange.
I understand a little bit more about USB now. But why are the majority of USB audio interfaces incapable of functioning off an external hub?
BTW I didn't mean ethernet over UTP, I was thinking about ethernet over Firewire.
I see both network and audio over Firewire completely outperforming USB. But you seem te believe USB is at an advantage because it is so primitive. Strange.
I understand a little bit more about USB now. But why are the majority of USB audio interfaces incapable of functioning off an external hub?
Creative X-Fi, I have written them about this and they blame the DELL. Obviously this is only on headphones and during quiet periods between tracks I had the problem with the on board chipsets and my reason for changing to stand alone. Obviously the problem is a thing of the past using a $1 solution.
My laptops don't seem to have this problem and I put it down to being battery powered.
Peufeu, you have solved the problem. Since I did not care whether the card worked or not I cut the power connection from the bus connector, then soldered wires and now run the sound card from a 12V battery (since there was on board regulators).
Took me five minutes to make the simple modification. There is plenty of space and I will place a nice regulated analog supply in the case for running the sound card.
The Creative Sound Card is now dead quiet and sound performance is beyond expectation. Thanks for pointing me in the right direction, I am in your debt.
Took me five minutes to make the simple modification. There is plenty of space and I will place a nice regulated analog supply in the case for running the sound card.
The Creative Sound Card is now dead quiet and sound performance is beyond expectation. Thanks for pointing me in the right direction, I am in your debt.
So would I. X-FI measurements in a properly working setup : Sound Blaster X-Fi Titanium HD review - Testing Regimen - Right Mark Audio Analyzer
Still, it's good that you got it working properly.
Hi All,
Have been reading here & there in this thread and find the observations interesting. I might have missed it but did someone also try evaluating various computers' USB connections? I've tried my DAC on three different computers (different generations) and they all sounded quite different with the newest one being more open, nuanced and detailed.
I didn't use any (galvanic) isolation, though, and wonder if that would make a (much?) difference.
Anyone with good experience in this?
Cheers,
Jesper
Have been reading here & there in this thread and find the observations interesting. I might have missed it but did someone also try evaluating various computers' USB connections? I've tried my DAC on three different computers (different generations) and they all sounded quite different with the newest one being more open, nuanced and detailed.
I didn't use any (galvanic) isolation, though, and wonder if that would make a (much?) difference.
Anyone with good experience in this?
Cheers,
Jesper
I have acquired an E-Mu 0202 USB.
It seems to need a bit of power. The USB port on the back of the computer always works. The one on the front makes it fail quite often. After checking, it runs through some rather high resistance wires to a header inside the tower PC box. The voltage drop on the tiny gauge wires is enough to disturb the soundcard.
I should try a powered hub...
It seems to need a bit of power. The USB port on the back of the computer always works. The one on the front makes it fail quite often. After checking, it runs through some rather high resistance wires to a header inside the tower PC box. The voltage drop on the tiny gauge wires is enough to disturb the soundcard.
I should try a powered hub...
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.