Russ,
I assume you're talking about the CCHD-957. The datasheet says that start-up time is 2ms max. I can't believe that phase noise (aka jitter) snaps into place that fast. Do they give any info on how fast the oscillator stabilizes? I'd think you'd be better off to have both oscillators running all the time and then gate the output as needed.
I assume you're talking about the CCHD-957. The datasheet says that start-up time is 2ms max. I can't believe that phase noise (aka jitter) snaps into place that fast. Do they give any info on how fast the oscillator stabilizes? I'd think you'd be better off to have both oscillators running all the time and then gate the output as needed.
A couple of reasons:
1) I want the device to be able to run under USB power (this will be optional) I simply don't have current to spare to keep 3 clocks running all the time.
2) a few milliseconds of clock stabilization won't be a problem at all because changing sample rates is not something that happens in the middle of music playback. I can even build a small delay and not start the receiving endpoint until I am ready.
Last edited:
Understood. Is there a approximate size? I would like to reserve the location in the chassis along with BIII. Thanks
Russ,
I'm not worried about the few ms, and I surely understand your power constraint. But, it's one thing for the clock to be putting out a signal in a few ms after power-up and its another thing to be stabilized. My experience is that until 'warmed up' the oscillator will not be operating to the low-phase-noise specs on the datasheet. Perhaps you can add an option to have clocks on for those who would wish to provide external power.
I'm not worried about the few ms, and I surely understand your power constraint. But, it's one thing for the clock to be putting out a signal in a few ms after power-up and its another thing to be stabilized. My experience is that until 'warmed up' the oscillator will not be operating to the low-phase-noise specs on the datasheet. Perhaps you can add an option to have clocks on for those who would wish to provide external power.
I understand completely, but since everything can be synched to the master clock this does not sound like anything to worry over (even the DAC).
One thing I don't want to do is put anything between the clocks and the processor.
What I can do is give the clocks as long as I feel prudent to "spin up" before enabling the input endpoint.
What are you planning to do? Switch sample rates between tracks?
Even if you were I could make that work just fine.
One thing I don't want to do is put anything between the clocks and the processor.
What I can do is give the clocks as long as I feel prudent to "spin up" before enabling the input endpoint.
What are you planning to do? Switch sample rates between tracks?
Even if you were I could make that work just fine.
Last edited:
perhaps...
another consideration. Having two (non integer) related clocks running at the same time may also cause power supply problems: the power supply may be modulated to some extent by the clock frequency, and this may cause more jitter at the output of the processor. Running both clocks off of isolated, very low impedance supplies, may alleviate this potential problem, but it appears to me that a simpler solution is to not have the two clocks (not to mention the third processor clock) running concurrently.
The question: how much ("warm up") time does a CCHD-957 to reach stable, specified, phase noise performance?
another consideration. Having two (non integer) related clocks running at the same time may also cause power supply problems: the power supply may be modulated to some extent by the clock frequency, and this may cause more jitter at the output of the processor. Running both clocks off of isolated, very low impedance supplies, may alleviate this potential problem, but it appears to me that a simpler solution is to not have the two clocks (not to mention the third processor clock) running concurrently.
The question: how much ("warm up") time does a CCHD-957 to reach stable, specified, phase noise performance?
...
I may end up needing to do the layout for multiple possible clocks if they can't. the other possibility is that the first batch may only support up to 192khz.
Do you expect a high demand for >192kHz?
Thanks for making an effort in keeping it (optionally) USB powered! Limiting the number of clocks seems to be the best approach there, and would also help keep the board size small.
Some HDD enclosures use a second USB connection to add more power. Not pretty, but it could be a solution until you decide to switch to a USB 3.0 design?
What are you planning to do? Switch sample rates between tracks?
Actually! this is one thing I wish USB to I2S devices did automatically! If i have a bunch of different tracks loaded up in a playlist at different sampling rates. I would like the USB/Dac system to automatically switch to whatever the native sampling rate of the track is! I have yet to see a device that works that way.
Zc
I am really hoping that the HDtracks type concept takes off! I would really like to be able to buy music at high bit/sampling rates. and not just old stuff resampled to a higher rate. I mean stuff remastered from original tapes and new music recorded to hi-rez from the get go!
$25 is a lot to pay for an album from HDtracks. but i would pay it if i knew that the source was hi-rez to begin with.
Sorry if this is a bit off topic. But I am hoping that the demand for HD audio takes off!
That is actually an application layer thing. If the application can take advantage of "exclusive mode", then the usb device will pass whatever sample rate it can support.
Huh...
If you use Pure Music on a Mac, or many other playback engines, along with one of the good async USB interfaces or DACs (Wavelength Audio, Ayre, dCS, etc) The system will automatically switch sample rates for you with mixed resolution playlists. Since TPAs forthcoming solution is XMOS based, as is Wavelength and Ayre (and many others) there is no reason it should not be able to operate similarly. The playback software is where the solution is. So there are lots of available solutions already that operate as you desire.
If you use Pure Music on a Mac, or many other playback engines, along with one of the good async USB interfaces or DACs (Wavelength Audio, Ayre, dCS, etc) The system will automatically switch sample rates for you with mixed resolution playlists. Since TPAs forthcoming solution is XMOS based, as is Wavelength and Ayre (and many others) there is no reason it should not be able to operate similarly. The playback software is where the solution is. So there are lots of available solutions already that operate as you desire.
Yes it, if you use playback software that supports it there is no issue switching between sample rates in a play list. And this board will support that without any issues. I will build a small (50 milliseconds or so) delay for the clock to settle before accepting data if a clock switch is required. This should be completely transparent.
There are some other nifty features I have on the board as well.
There will be the option to output the actual input master clock (buffered) or to output a 256fs (at least up to 192khz) clock which will be formed by dividing the base clock based on the input sample rate. This way a large number of DACs can be supported including Opus and COD etc.
There are more features, but more on those later.
There are some other nifty features I have on the board as well.
There will be the option to output the actual input master clock (buffered) or to output a 256fs (at least up to 192khz) clock which will be formed by dividing the base clock based on the input sample rate. This way a large number of DACs can be supported including Opus and COD etc.
There are more features, but more on those later.
Last edited:
- Status
- Not open for further replies.