Indeed, the USB receiver chip regenerates the clock. But look at how this is accomplished. The bus runs at 48MHz (I think), so the chip starts with a 12.000MHz xtal and multiplies that up to 96MHz (don't for a minute think that is jitter-free). From there, the processing is done and USB reception, etc. Now, from the audio packet timing (dependent on the PC clock, full of jitter) a new 44.1k clock is created. How? A complicated multi-loop PLL synthesizer. Haven't been able to dig deep into this, but probably a fractional loop from a VCO referenced to the 96MHz AND the USB packet delivery. So now you have two system clocks that are not harmonically related (12M/44.1k = 272.1088435...) in one chip. All running from the same supply, trying to spit out clean audio data. Oh, and it also has to decode 32k and 48k word clocks too, so operation is not narrowband.
Nonetheless, TI did a superb job and these USB chips work extremely well. But let's keep in mind the hoops they had to jump through to try and regenerate word clocks.
In my opinion, the USB audio output is ripe for reclocking with a dedicated narrowband VCXO running from a separate clean supply. I have confirmed this with my own testing.
jh
Here you can read about the development and workings of "SpAct"
http://www.planetanalog.com/story/OEG20020220S0017
Even if the jitter is plentifull it will not be as heavily signal correlated compared to if its been biphasemark encoded, and thus not as harmfull.
How did you, or how do you suggest to do this? A secondary Pll or mayb a fifo?
http://www.planetanalog.com/story/OEG20020220S0017
Even if the jitter is plentifull it will not be as heavily signal correlated compared to if its been biphasemark encoded, and thus not as harmfull.
How did you, or how do you suggest to do this? A secondary Pll or mayb a fifo?
Secondary PLL.......the kind of thing us RF guys love to futz with. (Yeah, I know......I'm sick.........)
Anyway, Mr. "making audio fun again" was kind enough to donate one of his thingies for me to delve into........(well, he really didn't expect me to delve into it, but he should have known better, right?)........and I will try to run some graphs on the recovered clock jitter, and compare them to what you get from a typical CDP driving my D/A box. No promises, but I plan to try.
Jocko
Anyway, Mr. "making audio fun again" was kind enough to donate one of his thingies for me to delve into........(well, he really didn't expect me to delve into it, but he should have known better, right?)........and I will try to run some graphs on the recovered clock jitter, and compare them to what you get from a typical CDP driving my D/A box. No promises, but I plan to try.
Jocko
I got one of tents PLL:s aswell...
Here is a measurement taken of the errorsignal from said PLL when driven by a PCM2902 playing regular music trough a spdif interface you would probably recognice....
I can hear no readily recognisable signal modulation of the errorsignal when i listen to it with a battery powered headphoneamp.
The measurement is taken with a regular soundcard (averaged 10 times).... But compared to the spectra of my Cdplayer I dare attribute most of the spikes to the pcm.
ofcourse a comparision to the clock comming directly out of a pcm27xx would be better...but in the meantime..
Here is a measurement taken of the errorsignal from said PLL when driven by a PCM2902 playing regular music trough a spdif interface you would probably recognice....
I can hear no readily recognisable signal modulation of the errorsignal when i listen to it with a battery powered headphoneamp.
The measurement is taken with a regular soundcard (averaged 10 times).... But compared to the spectra of my Cdplayer I dare attribute most of the spikes to the pcm.
ofcourse a comparision to the clock comming directly out of a pcm27xx would be better...but in the meantime..
Attachments
hagtech said:
isn't that pretty much what Doede did? His USB board that I am listening to right now has a 12mHz Tent clock on it. Hooked directly via I2s to the 16-chip TDA1543 tower on my last generation DDDAC build, the combo easily outperforms anything else I have played with in recent years (I'll spare you the list of devices, interface, cables, jacks, unless you really need to know)
For me, this little card pretty much marks the day I finally had a strong enough reason to move over to PC-based audio. It just sounds that much better, period.
This interface is also a mile ahead of USB-SPDIF interfaces and I've got two of them, but neither really rocked my boat enough to pull the plug on the CD transport, although they sounded very detailed and possibly better than the CD player, but it was a taste thing and not enough to even contemplate ripping hundreds of CDs to a file server. Now it's just blatantly obvious that I'll have to go and start working on that...
Peter
hagtech said:
JH,
What "most of the problems" are you referring to? This does not help me improving future designs....
YES, the Tent Clock helps, so there is nothing against a 29 Euro option where Audio companies sell upgrades for hundreds (or thousands) of Euros....
won’t we all agree?The DAC with USB input sounds just great, and you need to throw a lot of money on the table for commercial DACs or CD players to come close to this result...... that always has been the philosophy behind the DDDAC1543 designs....
I consider it to be very good, that my thread and published design has kicked loose a discussion on what could be even better in USB-audio (which would sound also better than just remarks on what is not good, even without having built and listened.... Short remark: Ulas, where are you by the way??? ) And I hope this will lead to Forum members really (and I mean really!!) work on this concept and come with solutions as well. And than I mean publish circuits which are tested, PCB designs which are actually built and make it available at a very reasonable price..... Than we have all won
Look forward to the first improved USB reclocked designs at this forum (really ...
)doede
If you read the article I linked to in post #25 you will see how the innards of the PCM2xxx works and how its clocking scheme is devised.
Replacing the 12Mhz oscillator with a low jitter one does not buy you all that much, it certainly will not hurt But it would be money better spent if it where used to reclock (synchronous) the i2s stream when it exits the Pcm.
Replacing the 12Mhz oscillator with a low jitter one does not buy you all that much, it certainly will not hurt But it would be money better spent if it where used to reclock (synchronous) the i2s stream when it exits the Pcm.
I spoke to this in post #23.
You can download schematics for the hagdac, hagusb, and chime at my website. The basic topology I chose was to use the S/PDIF output from the USB chip. A step backwards maybe? Or perhaps not. This allows me to run it through a transformer to isolate PC ground and PC power from the audio system. Ground isolation alone I think is worth the conversion. And most of the S/PDIF problems of transmission and connectors are eliminated since I keep the routing all on the same PC board (chime). Then, I do a VCXO-based PLL to reclock the audio right at the DAC, after the digital filter (the more gates you go through, the more jitter added). The PLL loop runs very slow and operates subsonically. It does take a few tenths of a second to lock, though. The flywheel action keeps audioband jitter really low. Biggest drawback is that it may not lock to transports or PCs that are out of the +/-100ppm redbook spec. I haven't seen this yet, but it is possible. Also, older transports were allowed up to 12UI at low frequencies (motor speed control?). The flywheel operation will not tolerate more than 0.5UI (~10ns jitter).
jh
OK.....I promised.......
Using a CD-80, with a "clocko jocko" inside, the recovered SPDIF clock is 43 dB noisier than "clocko jocko" by itself. This makes sense, as the jitter on the YM3623 is in the 1 nSec range, and "clocko jocko" is probably under 10 pSec. I did not fully calibrate the test set-up, but the close-in noise on "c-j" is around -130 dB/Hz^-2. Not bad, if my calibration is right. Actually, the close in noise on the recovered clock is around 15 dB lower than the HF noise, as it has an exponential rise, starting at around 250 Hz. Still, it leaves much to be desired.
Using a USB-SPDIF thingie, the clock noise is 7 dB noisier than the CD-80. In addition, there are spurious responses, too numerous to list. No, I don't have a way to display them here, so you guys will just have to trust Mr. RF is telling the truth.
Jocko
Using a CD-80, with a "clocko jocko" inside, the recovered SPDIF clock is 43 dB noisier than "clocko jocko" by itself. This makes sense, as the jitter on the YM3623 is in the 1 nSec range, and "clocko jocko" is probably under 10 pSec. I did not fully calibrate the test set-up, but the close-in noise on "c-j" is around -130 dB/Hz^-2. Not bad, if my calibration is right. Actually, the close in noise on the recovered clock is around 15 dB lower than the HF noise, as it has an exponential rise, starting at around 250 Hz. Still, it leaves much to be desired.
Using a USB-SPDIF thingie, the clock noise is 7 dB noisier than the CD-80. In addition, there are spurious responses, too numerous to list. No, I don't have a way to display them here, so you guys will just have to trust Mr. RF is telling the truth.
Jocko
I had some email comments and questions on the windows kmixer. And the possible influence on bit cooretness...
I am not sure about this case. The USB versio sounds so good in comparison to SPDIF and normal CD Player, you would expect no bit pampering.... but not sure....
Any way, I thougt it might be a an idea to create a wav file with a very clear data patern, like a squarewave using bit 14,15 and 16 running at 11025 Hz for example.... and check this data on the digital scope. If tampered, it should look like a prety mess I guess. Any one already some xperience or ideas ?
I am not sure about this case. The USB versio sounds so good in comparison to SPDIF and normal CD Player, you would expect no bit pampering.... but not sure....
Any way, I thougt it might be a an idea to create a wav file with a very clear data patern, like a squarewave using bit 14,15 and 16 running at 11025 Hz for example.... and check this data on the digital scope. If tampered, it should look like a prety mess I guess. Any one already some xperience or ideas ?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.