Svart
Well-known member
But in response to something you said in your last post, I would stay with flash ram for your storage. Even computers are going to move to that and away from HDDs now.
A portable digital multi-track recorder -- proto-pr0n
- Thread starter jdbakker
- Start date
Help Support GroupDIY Audio Forum:
how about using a sample rate converter?
Svart
Well-known member
the basis is similar I suppose but I don't intend to change the frequency, only lower the jitter of the clock to an acceptable level.
I was just pointing out that some people use an SRC to sync up signals from an external source to an internal clock, even if they are running at the same sample rate.
Svart
Well-known member
ah I see. I am using an ADAT receiver ic that generates a master clock for the AD/DA ICs as well as the ADAT transmitter. It generates that based on the word timing.
The problem is that the ADAT IC that generates this clock does so with a spec'd jitter of ~1.5ns of jitter and the AD/DA would prefer to see less than 100ps of jitter although it is supposed to be tolerant of high jitter.
I'd like to take that generated clock and "clean" it up, in other words, reduce the jitter to something more tolerable before sending it to the other ICs.
The problem is that the ADAT IC that generates this clock does so with a spec'd jitter of ~1.5ns of jitter and the AD/DA would prefer to see less than 100ps of jitter although it is supposed to be tolerant of high jitter.
I'd like to take that generated clock and "clean" it up, in other words, reduce the jitter to something more tolerable before sending it to the other ICs.
jdbakker
Well-known member
Mohammed vs the mountain: you mention ADAT to AD/DA. The best possible jitter performance can be achieved by making the AD/DA the clock master, and ensuring that the AD/DA clock has low jitter (by using clocks like the Kwak clock or the Tent XO). All other factors being equal, oscillator jitter performance is determined by the Q of its resonant circuit (higher Q = less jitter), and a voltage controlled oscillator (required when the AD/DA has to lock to ADAT) will by definition need to have a lower Q than a fixed-frequency oscillator. So if you can get away with it, lock ADAT to AD/DA and not the other way around (prevention vs cure and all that). With a little care you can get <10ps jitter (and with lots of care, a PhD in RF design and a solid dose of OCD you might get <1ps).
If this isn't possible for technical or political reasons, Rochey is right that an Asynchronous Sample Rate Converter (ASRC) is a good way to go. Don't get too hung up on the sample-rate conversion; ASRCs are being used for jitter rejection in lots of high-end equipment nowadays. Think about it: to convert from rate x to rate y, an ASRC needs to know the ratio x/y between its input and output clocks. Very roughly speaking, it uses a digital PLL to lock to the incoming signal. Because the bandwidth of this PLL is relatively narrow, its jitter rejection performance can be very good. For more info, see page 34 and onward of the TI SRC4392 datasheet (particularly figure 73 showing the jitter filter performance), or AN270 from Cirrus Logic, showing how SRCs can help you keep separate clock domains. The downside is that, due to DPLL noise and the like, a very small bit of the phase noise will get 'mixed into' the post-SRC signal (but still less than what you'd see when the ADAT were to directly clock a DAC).
If you must use an external sync, word clock over BNC can have better jitter performance than a regenerated ADAT clock. However, I know of no existing ASRC that will lock to a word clock (as opposed to bit clock), so you'll need to roll your own PLL.
Me, I'm planning to use a mix of an ASRC (likely the SRC4392 if I can manage the 0.5mm pin pitch, or else the CS8421) and a hand-rolled PLL. For the PLL I think I'll use a low noise high frequency crystal clock driving an Analog Devices Direct Digital Synthesis (DDS) chip, with an AVR microcontroller providing the frequency/phase detection and correction. A free-running crystal oscillator will drift less than a PPM per minute, which is easily tracked with the DDS. If and when I ever get this working, I'll post a comparison of jitter rejection between the ASRC and the DDS PLL.
Plenty to do,
JDB.
[EDIT: Yet Another Typo]
If this isn't possible for technical or political reasons, Rochey is right that an Asynchronous Sample Rate Converter (ASRC) is a good way to go. Don't get too hung up on the sample-rate conversion; ASRCs are being used for jitter rejection in lots of high-end equipment nowadays. Think about it: to convert from rate x to rate y, an ASRC needs to know the ratio x/y between its input and output clocks. Very roughly speaking, it uses a digital PLL to lock to the incoming signal. Because the bandwidth of this PLL is relatively narrow, its jitter rejection performance can be very good. For more info, see page 34 and onward of the TI SRC4392 datasheet (particularly figure 73 showing the jitter filter performance), or AN270 from Cirrus Logic, showing how SRCs can help you keep separate clock domains. The downside is that, due to DPLL noise and the like, a very small bit of the phase noise will get 'mixed into' the post-SRC signal (but still less than what you'd see when the ADAT were to directly clock a DAC).
If you must use an external sync, word clock over BNC can have better jitter performance than a regenerated ADAT clock. However, I know of no existing ASRC that will lock to a word clock (as opposed to bit clock), so you'll need to roll your own PLL.
Me, I'm planning to use a mix of an ASRC (likely the SRC4392 if I can manage the 0.5mm pin pitch, or else the CS8421) and a hand-rolled PLL. For the PLL I think I'll use a low noise high frequency crystal clock driving an Analog Devices Direct Digital Synthesis (DDS) chip, with an AVR microcontroller providing the frequency/phase detection and correction. A free-running crystal oscillator will drift less than a PPM per minute, which is easily tracked with the DDS. If and when I ever get this working, I'll post a comparison of jitter rejection between the ASRC and the DDS PLL.
Plenty to do,
JDB.
[EDIT: Yet Another Typo]
jdbakker
Well-known member
Project update: still working on the HDD interface. I've spent the last two weeks trying very hard to stick to easily solderable parts (ie pin pitch >= 0.8mm). Trouble is that most high-density logic devices come in small pitch packages, and using 0.8mm pitch programmable logic would mean wiring up between 8 and 10 CPLD chips and a dozen buffers, and that was just too Seventies for me (not to mention the timing nightmare involved in getting the state machines in 10 CPLDs running in lock-step). So now I've caved, and I've switched the design over to a Xilinx XC2C256 CPLD in a 0.5mm pitch 100-TQFP package. I'm still very wary of soldering those buggers, so I'm working on a header board with that chip only (plus decoupling caps etc), so that when I butcher the soldering job for one of those I don't have to scrap the entire Hard Disk Recorder board.
For a plan B I've ordered an XESS XSA-200 FPGA board, a huge chunk of programmable logic on a standalone proto board. It consumes a bit more power than I'd like (we're still talking just a few hundred mA @ 3.3V), but it's guaranteed to be large enough to hold my design and then some. And at $89 it's as cheap as building one yourself, even if your design/soldering time is free.
BTW, the nice thing about programmable logic is that you can Fix It In The Mix (yeah, I know...): small logic errors can be corrected by in-circuit reprogramming of the chip rather than the use of scalpel and patch wire.
[quote author="Svart"]But in response to something you said in your last post, I would stay with flash ram for your storage. Even computers are going to move to that and away from HDDs now.[/quote]
I passionately hate NAND Flash (used in all current large-capacity Flash products). Like early-'80s hard disks, they come from the factory with a non-empty list of defective blocks, which only grows over the lifetime of the device. All consumer-level Flash products (USB sticks, CF, SD etc) have controllers which hide this behaviour from the user by marking bad blocks and moving data out of them to spare sectors. This housekeeping takes time, up to 100ms depending on access/defect patterns. No big problem for a digital camera, no fun at all when you're trying to stream eight 24/96 audio channels to the card. This is why I'm including two recorders in the system: a CF card accessible from the front panel for session recording, a non-removable hard disk as a backup.
JDB.
For a plan B I've ordered an XESS XSA-200 FPGA board, a huge chunk of programmable logic on a standalone proto board. It consumes a bit more power than I'd like (we're still talking just a few hundred mA @ 3.3V), but it's guaranteed to be large enough to hold my design and then some. And at $89 it's as cheap as building one yourself, even if your design/soldering time is free.
BTW, the nice thing about programmable logic is that you can Fix It In The Mix (yeah, I know...): small logic errors can be corrected by in-circuit reprogramming of the chip rather than the use of scalpel and patch wire.
[quote author="Svart"]But in response to something you said in your last post, I would stay with flash ram for your storage. Even computers are going to move to that and away from HDDs now.[/quote]
I passionately hate NAND Flash (used in all current large-capacity Flash products). Like early-'80s hard disks, they come from the factory with a non-empty list of defective blocks, which only grows over the lifetime of the device. All consumer-level Flash products (USB sticks, CF, SD etc) have controllers which hide this behaviour from the user by marking bad blocks and moving data out of them to spare sectors. This housekeeping takes time, up to 100ms depending on access/defect patterns. No big problem for a digital camera, no fun at all when you're trying to stream eight 24/96 audio channels to the card. This is why I'm including two recorders in the system: a CF card accessible from the front panel for session recording, a non-removable hard disk as a backup.
JDB.
don't forget to share the pll design. 
Svart
Well-known member
If the source is clocked from the computer that the adat optical is going to, couldn't that cause a problem if the box is clocked to itself? I figured that clocking the unit to the word would be the most solid way to get everything to sync regardless of the source of the word. That's the reason I would like to take the clock from the input IC and clean it up.
jdbakker
Well-known member
[quote author="Svart"]If the source is clocked from the computer that the adat optical is going to, couldn't that cause a problem if the box is clocked to itself?[/quote]
I'm not quite sure what you mean here. What is 'the source' ? The A/D ? Which box is clocked to itself ?
[quote author="Svart"]I figured that clocking the unit to the word would be the most solid way to get everything to sync regardless of the source of the word.[/quote]
By 'the word', do you mean the BNC Word Clock input or the recovered clock from the ADAT receiver chip ?
Maybe this is the source of the confusion:
[quote author="Svart"]That's the reason I would like to take the clock from the input IC and clean it up.[/quote]
You could do that, but a cleaned clock will always have more jitter than a freshly generated one (all else being equal, naturally).
If you must absolutely positively definitely lock your AD/DA to an external clock, have a look at AES11-2003 and use an AES input to a Cirrus CS8416 (200ps jitter spec) or a TI DIX4192 (250ps jiitter spec).
JDB.
[apropos synchronization issues: varispeed is evil. Whoever thought up that harebrained scheme ?]
I'm not quite sure what you mean here. What is 'the source' ? The A/D ? Which box is clocked to itself ?
[quote author="Svart"]I figured that clocking the unit to the word would be the most solid way to get everything to sync regardless of the source of the word.[/quote]
By 'the word', do you mean the BNC Word Clock input or the recovered clock from the ADAT receiver chip ?
Maybe this is the source of the confusion:
If you're using the AL1402, keep in mind that while it accepts a wordclock input signal, its output clocks will still be very jittery.
[quote author="Svart"]That's the reason I would like to take the clock from the input IC and clean it up.[/quote]
You could do that, but a cleaned clock will always have more jitter than a freshly generated one (all else being equal, naturally).
If you must absolutely positively definitely lock your AD/DA to an external clock, have a look at AES11-2003 and use an AES input to a Cirrus CS8416 (200ps jitter spec) or a TI DIX4192 (250ps jiitter spec).
JDB.
[apropos synchronization issues: varispeed is evil. Whoever thought up that harebrained scheme ?]
Svart
Well-known member
yes I think there is confusion.
Lets say that I am using a PCI card with ADAT opto I/O and a separate AD/DA box connected to each other with fibers.
the receiver IC (al1402) generates it's own word/bit/LR clocks via an internal PLL which gets it's timing from the optical datastream. It's jittery, a little over 1ns. This keeps the timing based on the datastream from the PCI card.
Wavefront claims this is the best way to keep sync between your datasource and the ADDA box. It sounds logical to me.
What I am wondering about is if we clock the ADDA box separately from the datastream, won't we create a scenario for a time misalignment between the ADDA box and the computer?
Lets say that I am using a PCI card with ADAT opto I/O and a separate AD/DA box connected to each other with fibers.
the receiver IC (al1402) generates it's own word/bit/LR clocks via an internal PLL which gets it's timing from the optical datastream. It's jittery, a little over 1ns. This keeps the timing based on the datastream from the PCI card.
Wavefront claims this is the best way to keep sync between your datasource and the ADDA box. It sounds logical to me.
What I am wondering about is if we clock the ADDA box separately from the datastream, won't we create a scenario for a time misalignment between the ADDA box and the computer?
jdbakker
Well-known member
[quote author="Svart"]Wavefront claims this is the best way to keep sync between your datasource and the ADDA box. It sounds logical to me.[/quote]
[cynical]Wavefront is also in the business of selling these chips.[/cynical]
All kidding aside, I would agree with Wavefront when the data is going from the A/D to the computer. Computers (and to a certain extent other DAWs) don't care much about incoming jittter; as long as everything remains in the digital domain jitter has zero impact.
[quote author="Svart"]What I am wondering about is if we clock the ADDA box separately from the datastream, won't we create a scenario for a time misalignment between the ADDA box and the computer?[/quote]
That's why most PCI ADAT cards have Word Clock In. The RME HDSP9652 has this option, and (I believe) also the possibility to use incoming ADAT to sync outgoing ADAT, so that you can use your AD/DA as clock master.
JDB.
[cynical]Wavefront is also in the business of selling these chips.[/cynical]
All kidding aside, I would agree with Wavefront when the data is going from the A/D to the computer. Computers (and to a certain extent other DAWs) don't care much about incoming jittter; as long as everything remains in the digital domain jitter has zero impact.
[quote author="Svart"]What I am wondering about is if we clock the ADDA box separately from the datastream, won't we create a scenario for a time misalignment between the ADDA box and the computer?[/quote]
That's why most PCI ADAT cards have Word Clock In. The RME HDSP9652 has this option, and (I believe) also the possibility to use incoming ADAT to sync outgoing ADAT, so that you can use your AD/DA as clock master.
JDB.
Svart
Well-known member
ok, I'm still beating a dead horse until I can prove that it won't move anymore.. :green:
cdcvf25081 from TI, a clock driver with 8 outputs(one per bank of quad ADC/DAC) that has an internal PLL that I can use to clean up the signal from the wavefront IC. Think it might have a chance?
Another choice is the pll1707 to generate my own clock.
One more question regarding the different clocks needed. Do I specifically need to generate the bclk and such from the same source as the master clock? What if I drive the master clock inputs with my own PLL while allowing the adat ICs to generate the bclkc and lrclk?
cdcvf25081 from TI, a clock driver with 8 outputs(one per bank of quad ADC/DAC) that has an internal PLL that I can use to clean up the signal from the wavefront IC. Think it might have a chance?
Another choice is the pll1707 to generate my own clock.
One more question regarding the different clocks needed. Do I specifically need to generate the bclk and such from the same source as the master clock? What if I drive the master clock inputs with my own PLL while allowing the adat ICs to generate the bclkc and lrclk?
whats needed here is a decent PLL circuit - that's open source and anyone can use!
thats the easy bit... it's the filtering/controlling part i'm not so sure about.
Do you think we should start another thread for the PLL?
thats the easy bit... it's the filtering/controlling part i'm not so sure about.
Do you think we should start another thread for the PLL?
jdbakker
Well-known member
[quote author="Svart"]cdcvf25081 from TI, a clock driver with 8 outputs(one per bank of quad ADC/DAC) that has an internal PLL that I can use to clean up the signal from the wavefront IC. Think it might have a chance?[/quote]
Oh, it'll work. No clue as to how much jitter attenuation you'll get, since neither the data sheet nor the app note make any mention of this. From my interpretation of the data sheet you can expect 150ps jitter even when the part is clocked by a jitter-free clock.
[quote author="Svart"]Another choice is the pll1707 to generate my own clock.[/quote]
Sure, but why ? Do you have a readily available 27MHz clock ? These parts were designed for low-$ set top box applications, not for top-notch performance. Jitter performance will be an order of magnitude worse than a simple crystal oscillator.
[quote author="Svart"]One more question regarding the different clocks needed. Do I specifically need to generate the bclk and such from the same source as the master clock?[/quote]
As far as I can tell, most converters want MCLK, BCLK and LRCK to have the same rate (ie no cycle slippage); having them synchronized is encouraged but not mandatory.
Svart, I have to ask: why ? A nice simple crystal oscillator plus a divider like the HC4040/LV4040 will give you better performance than any scheme that tries to filter the jitter out. Any particular reason why you insist on doing it the hard way ?
JDB
Oh, it'll work. No clue as to how much jitter attenuation you'll get, since neither the data sheet nor the app note make any mention of this. From my interpretation of the data sheet you can expect 150ps jitter even when the part is clocked by a jitter-free clock.
[quote author="Svart"]Another choice is the pll1707 to generate my own clock.[/quote]
Sure, but why ? Do you have a readily available 27MHz clock ? These parts were designed for low-$ set top box applications, not for top-notch performance. Jitter performance will be an order of magnitude worse than a simple crystal oscillator.
[quote author="Svart"]One more question regarding the different clocks needed. Do I specifically need to generate the bclk and such from the same source as the master clock?[/quote]
As far as I can tell, most converters want MCLK, BCLK and LRCK to have the same rate (ie no cycle slippage); having them synchronized is encouraged but not mandatory.
Svart, I have to ask: why ? A nice simple crystal oscillator plus a divider like the HC4040/LV4040 will give you better performance than any scheme that tries to filter the jitter out. Any particular reason why you insist on doing it the hard way ?
JDB
jdbakker
Well-known member
I was planning to do a PLL for my all-singing all-dancing recorder, but the more I think about it the more I get convinced that a crystal oscillator at the converter is the best way to go (possibly locked to a oven controlled master clock, but that's another story). The jitter reduction provided by an ASRC like the TI SRC4392 is a good alternative if you're forced to lock to an external clock.
I'd still like to do something like:
[quote author="Rochey"]
[/quote]
with a microcontroller driving a very slow integrator for the control part, and either a VCXO or a very low noise VCO (like one of the Mini-Circuits parts) for the oscillator, if only to see how good the jitter filtering in the SRC4392 really is.
The truly nasty bit about syncing to 44k1/48k word clock is that you have so very little information in your incoming signal. We get an edge every 10us (~2 x 1/48KHz, using both rising and falling edges), and we care about noise in the 10..100ps range. That's five to six decades !
[quote author="Rochey"]Do you think we should start another thread for the PLL?[/quote]
If you like; I don't mind doing it here.
JDB.
I'd still like to do something like:
[quote author="Rochey"]
with a microcontroller driving a very slow integrator for the control part, and either a VCXO or a very low noise VCO (like one of the Mini-Circuits parts) for the oscillator, if only to see how good the jitter filtering in the SRC4392 really is.
The truly nasty bit about syncing to 44k1/48k word clock is that you have so very little information in your incoming signal. We get an edge every 10us (~2 x 1/48KHz, using both rising and falling edges), and we care about noise in the 10..100ps range. That's five to six decades !
[quote author="Rochey"]Do you think we should start another thread for the PLL?[/quote]
If you like; I don't mind doing it here.
JDB.
Svart
Well-known member
The Pll1707 will accept a 27mhz crystal for it's timing. I have tons of those lying around.
Well "hard" is relative. My instinct is to keep those clocks aligned perfectly to each other and it's hard to shake.
I know I don't know enough about PLLs to be able to really tell though, but a crystal and divider circuit seems just as easy as a crystal and a purpose built IC.
Well "hard" is relative. My instinct is to keep those clocks aligned perfectly to each other and it's hard to shake.
I know I don't know enough about PLLs to be able to really tell though, but a crystal and divider circuit seems just as easy as a crystal and a purpose built IC.
jdbakker
Well-known member
[quote author="Svart"]Well "hard" is relative. My instinct is to keep those clocks aligned perfectly to each other and it's hard to shake.
I know I don't know enough about PLLs to be able to really tell though, but a crystal and divider circuit seems just as easy as a crystal and a purpose built IC.[/quote]
I meant that PLL-ing a clock is "hard" compared to an oscillator + divider; I'd agree that a PLL1707-based solution has comparable complexity wrt a clock+divider. The PLL1707 will give you more flexibility (microcontroller-driven switching between 44k1 and 48k); a clock+divider will give better performance. Up to you.
Naturally the clocks must remain in-sync, so if you implement a local master clock in your A/D-D/A you must get your computer/DAW to slave to this, either over ADAT or with a BNC wordclock cable.
JDB.
[who has just succeeded in soldering a 0.5mm pitch 48-TQFP to a test board ! Yay !]
I know I don't know enough about PLLs to be able to really tell though, but a crystal and divider circuit seems just as easy as a crystal and a purpose built IC.[/quote]
I meant that PLL-ing a clock is "hard" compared to an oscillator + divider; I'd agree that a PLL1707-based solution has comparable complexity wrt a clock+divider. The PLL1707 will give you more flexibility (microcontroller-driven switching between 44k1 and 48k); a clock+divider will give better performance. Up to you.
Naturally the clocks must remain in-sync, so if you implement a local master clock in your A/D-D/A you must get your computer/DAW to slave to this, either over ADAT or with a BNC wordclock cable.
JDB.
[who has just succeeded in soldering a 0.5mm pitch 48-TQFP to a test board ! Yay !]
Svart
Well-known member
48-TQFP?
Child's play.. :green:
I want to design flexability into the unit, I'd like to start with the clock based from the incoming data to get the thing working then step up to a better clocking system for when I fully understand how this will work out.
Child's play.. :green:
I want to design flexability into the unit, I'd like to start with the clock based from the incoming data to get the thing working then step up to a better clocking system for when I fully understand how this will work out.
[quote author="Viitalahde"]Didn't Mikkel C. Simonsen have a similar project once?[/quote]
Yes. And if only I had some time I would have finished it years ago... But I'll surely get some work done during the xmas holidays! But that's what I thought last year also :evil:
Best regards,
Mikkel C. Simonsen
Yes. And if only I had some time I would have finished it years ago... But I'll surely get some work done during the xmas holidays! But that's what I thought last year also :evil:
Best regards,
Mikkel C. Simonsen
Similar threads
