By the way, I'm a little new to the list, someone give me and Chris M. a nudge if this gets a little too audio-specialized and you want us to take this off list.
> The Silicon Labs DSPLL(TM) chip is a 3 port device... I'm pretty familiar with the SiLabs devices, those are the ones I investigated before giving up as not suitable for audio. Your mileage may vary. I may have to re-evaluate my opinion as well, I noticed a few things I had missed before after you mentioned them. > The frequency is not as critical (long term) e.g., aging. Which is why I wondered why all the drama with the expensive oven units. Why not just put a $10 TCXO on there and spend the savings elsewhere? > Yes, the DSPLL is a little bit of a different animal from conventional > VCXO PLLs perhaps? Yes and no. The principles are the same, but you get different artifacts because you are effectively moving to a sampled domain for clock control. Spurs in the phase noise, for example. > I can also get every frequency I desire out of this Silicon Labs part Yes, but the performance is not identical for every input/output frequency relationship. SiLabs have done some really clever things to minimize those kinds of problems, but look very closely at the phase noise plots, you'll see some significant spurs, and the 1/f corner frequency is too high for my liking. > Labs chip is in the $30 range with no need for a VCXO (albeit an > ovenized oscillator Why the big hang up on ovenized? AES11 recommends 1ppm for multi-studio synchronization systems, and just 10ppm for single studio systems. You could do a couple ppm with TCXO, especially if you don't plan on taking your equipment outdoors, i.e. it will stay in a narrow temperature range. > The Silicon Labs also provides great jitter specs for the SONET crowd > in the femtosecond region (caveat BW of measurement)... Are you talking about the Si5319, or something in that range? Look at the phase noise specs. At 100Hz offset just -65dBc/Hz. Not too expensive quartz oscillators can do -125dBc/Hz, good ones can do -135dBc or -145dBc at 100Hz offset from carrier. The Si5319 doesn't really hit its stride until 100kHz offset from carrier, which is way outside what you care about for audio sampling. [Came back to edit this: just noticed that those phase noise numbers were with a 622MHz output, so you can't compare apples to apples by looking at a dBc/Hz number for a 12MHz clock; I wish they would just use absolute numbers, s/Hz values; If that phase noise plot scales, it would be about -95dBc/Hz for 12MHz, which is not bad, but still not as good as you could get with a clean fundamental crystal). The Si5300 seems to have a phase noise floor that increases at around 60dB/decade from 1000Hz down. That makes me a little nervous for audio use because it is starting to increase rapidly while still in the frequency range that can cause audible sidebands. Also, the datasheet just shows telecom frequencies, I would want to measure and verify the performance with the intended input/output frequencies, and also verify that no spurs popped up if the input clock was a little off nominal, e.g. use a VCXO as an input, and sweep it through its adjustment range while monitoring the output of the synthesizer phase noise. Do you have an eval board and a way to measure phase noise? I could probably hook you up with an eval board if you need it, but I don't have anything that can measure phase noise down to those levels at the moment. > With these DSP based PLLs and clock distribution I am probably going > to be somewhere just below 1ps of jitter.... Single numbers like that are not as useful as phase noise plots. Look at the AES preprints from Chris Travis and Bruno Putzeys, they have a lot more to say on the subject than is appropriate for this email. Preprint 6122 by Putzeys is especially good, as is 6293 by Chris Travis. > This is a good idea... I have thought about copying and distributing > the 38.88MHz external to the box as a master clock for other DSPLL > based boxes, I meant either generate 44.1kHz word clock directly, or send the clock to an AES3 transmitter with data line muted AES11 style, or send the 11.2896MHz clock out like Digidesign does for their so-called "SuperClock" inputs. 38.88MHz is pretty unusual, only your custom equipment would be able to use it. If this is a two channel mastering studio, how many analog conversions are you going to have? If you do all the processing digital, only the A/D and D/A need the clean clocks, everything else just needs to be able to recover the data with no errors. If you are doing lots of conversions because you still have a lot of analog processing then I could see why you might need several devices with the supremo PLL's inside. > internal oversampling frequencies desired by their converters or > DSPs) Only conversion between domains matters (analog to digital, or digital to analog). Anything which is digital in to DSP to digital out can have a pretty nasty clock and still work fine. They are just synchronous digital designs, so clock jitter has no effect on operation. > of the world with standard mfg practices for house word clock only: > <http://www.antelopeaudio.com/en/products_iso_ocx.html Odd that the so-called data sheet contains absolutely no objective performance information, don't you think? > The ovenized can also be the internal clock if there are no external > clocks to synch to in a standalone application Yeah, but a TCXO would be almost as good, and about 1/10th the cost. I still have to ask, why is it so important to have an oven? Ovens buy you long term stability, and better absolute accuracy, neither of which is terribly important in this application. >> This is a baseband sampling application, so phase noise on the >> sampling clock is converted to sidebands on the output > Ah.. I've been wondering about this... Then definitely go get those preprints. Required reading before you fire up the schematic editor again. > I am ultimately looking to use a rubidium for the real long > term system reference and generate house word clocks Why? What would be the benefit to having the absolute accuracy that you get from rubidium? The outputs of a rubidium oscillator are a quartz based circuit, so the short term performance (i.e. jitter or phase noise) is going to be driven by the quality of the quartz circuitry, so the only thing rubidium buys is low long term drift. That has its place and uses, but I'm not sure audio synchronization is one of them. Knock yourself out if you just want it, I like things with ium in the name as much as anyone, but I don't see the functional benefit. > Yah, I was originally going with a $33/each 2 layer PCB So you were going to buy a $250 ovenized oscillator instead of a TCXO, and then scrimp on the PCB? I hope I don't offend your sensibilities, but I would make this box completely differently than the approach you are taking. Implementation is 80% when you are trying to keep noise levels this low, and you can completely screw up a great device with a bad PCB layout, bad power layout design, noisy power supply, etc. > into the PCB, with sharp edges for EMI purposes; then we get into > blind and buried vias perhaps... Buried vias for EMI? Won't make a noticeable difference. For practical purposes vias don't radiate. The loop area through a via is so small compared to your loop area along the rest of the route that vias will be the least of your worries. By the way, what converters were you planning? Those numbers you quoted earlier sound a lot like the new ESS Tech specs. -- Chris Caudle _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.