The jitter is determined only by the crystal oscillator near the ADC/DAC (and its power supply etc. around it of course). The jitter of the USBStreamer has no relevance, since it is just a clock slave.
I made this interface because I wanted something which would allow me to use a clean clock on an audio interface. I have also worked with SPDIF based solutions, which can also be made "perfect" in terms of clock quality. But I wanted to eliminate some of the limitations of the SPDIF (and Toslink).
1. On many computers (laptops) it is not available.
2. Only a relatively small number of sound cards support operation as a clock slave at 192 kHz. Many of them have limitations in this respect.
3. Even if the sound card does support slave operation and 192 kHz, it may be inconvenient to switch sample frequency, when operating in slave mode. It will probably be necessary to switch it both on the ADC/DAC and in the PC application.
So, I guess the answer is no. At the moment I don't see any need for changes. I did have a couple of small issues along the way, but the latest version works as I intended.
I made this interface because I wanted something which would allow me to use a clean clock on an audio interface. I have also worked with SPDIF based solutions, which can also be made "perfect" in terms of clock quality. But I wanted to eliminate some of the limitations of the SPDIF (and Toslink).
1. On many computers (laptops) it is not available.
2. Only a relatively small number of sound cards support operation as a clock slave at 192 kHz. Many of them have limitations in this respect.
3. Even if the sound card does support slave operation and 192 kHz, it may be inconvenient to switch sample frequency, when operating in slave mode. It will probably be necessary to switch it both on the ADC/DAC and in the PC application.
So, I guess the answer is no. At the moment I don't see any need for changes. I did have a couple of small issues along the way, but the latest version works as I intended.
I am really interested in this item (the only reason I was in this thread, actually). I don't read Chinese. Is there any news for US release of this item???
The last update on the QuantAsylum.com US page was last October....
What method are you using to measure the jitter? Is the the jitter originating from the miniDSP clock or is it because there's a processor involved?
David,
Take a look at this:
http://www.diyaudio.com/forums/attachments/digital-source/387610d1387043420-master-clock-isolator-minidsp-usbstreamer-usbstreamer-interface-v5-block-diagram-clock-path_131214.pdf
As you can see on the last page V3, V4 and V5 rely on a clock signal from the ADC/DAC board or wherever it might be placed.
In that way the jitter from the MiniDSP USBStreamer is irrelevant. There will be some jitter on the SCLK, LRCK and data, but if the converter is a type, which uses the MCLK as the reference, the jitter doesn't matter.
So the principle allows a jitter free system. Then it is up to the oscillator and the design around it to come as close as possible to this goal. The MiniDSP USBStreamer is out of the equation with this design. In itself the MiniDSP USBStreamer does have quite a lot of jitter. That's one of the reasons I made this interface. The other reason was to get a galvanic isolation.
Take a look at this:
http://www.diyaudio.com/forums/attachments/digital-source/387610d1387043420-master-clock-isolator-minidsp-usbstreamer-usbstreamer-interface-v5-block-diagram-clock-path_131214.pdf
As you can see on the last page V3, V4 and V5 rely on a clock signal from the ADC/DAC board or wherever it might be placed.
In that way the jitter from the MiniDSP USBStreamer is irrelevant. There will be some jitter on the SCLK, LRCK and data, but if the converter is a type, which uses the MCLK as the reference, the jitter doesn't matter.
So the principle allows a jitter free system. Then it is up to the oscillator and the design around it to come as close as possible to this goal. The MiniDSP USBStreamer is out of the equation with this design. In itself the MiniDSP USBStreamer does have quite a lot of jitter. That's one of the reasons I made this interface. The other reason was to get a galvanic isolation.
Hi Rick,
Don't know why your post didn't appear here.
GigaByte lan requires clock jitter well below 1ps. So yes there are clocks available in the fs rms noise. The manufactures don't give very thorough data in their briefs. Perhaps the data sheets more detailed.
Don't know why your post didn't appear here.
GigaByte lan requires clock jitter well below 1ps. So yes there are clocks available in the fs rms noise. The manufactures don't give very thorough data in their briefs. Perhaps the data sheets more detailed.
Demian have you looked at this? It accepts 4 aux ADC inputs which have access to the DPS.
It's a 13 dollar part. Runs to 192ksps.
No need to isolate the master clock or even synchronize it. The AK5394 can run in slave mode.
It's a 13 dollar part. Runs to 192ksps.
No need to isolate the master clock or even synchronize it. The AK5394 can run in slave mode.
Beware of jitter specs published. You need to see the plot. the usual spec is for a high speed network and the lowest frequency is usually 12 KHz. It's easy to get sub picosecond jitter with a clock that would be really noisy for audio. Use this JitterTime.com: Phase Noise Calculator with the actual plot to get a better idea. AES uses the band from 50 KHz to 100 Hz but I would go to 10 Hz just in case. Adding jitter above the highest frequency of interest (top of the passband) is not useful since it won't have an effect. For 192 KHz I would include up to 200 KHz.
So this is what I get for a Fox oscillator claiming extremely low jitter.
They also claim jitter decreases with frequency.
Attachments
Last edited:
I know those well. The DAC/ADC are OK and the processing is very good. We used a variation to make a game effects box. I have demo boards for two of the variations.
All the Sigma DSP stuff is very capable. One could make a complete audio analyzer out of one of these and something for a display. It would get close to what you can do with the QA400 but no further and you still need to cross the hurdles to get to a host computer to do more. Playing with the effects it offers is lots of fun. The USB interfaces are very fragile. Get extras. They break a lot.
All the Sigma DSP stuff is very capable. One could make a complete audio analyzer out of one of these and something for a display. It would get close to what you can do with the QA400 but no further and you still need to cross the hurdles to get to a host computer to do more. Playing with the effects it offers is lots of fun. The USB interfaces are very fragile. Get extras. They break a lot.
What I have in mind is to put a pair of 5394 in front of it. I just need a sum divide function to average the 5394 then out to the PC. Not planning on using the USB device other than programming.
I think it would work well for that. It can do so much else as well. Is there anything else we could do with it? The Sigma Studio control software is really good. How would you load the system? Some of the Sigma DSP's will autoload, no micro needed.
Right now I know of several efforts around a measurement grade AD-DA. I need to get them in sync so there is little redundant effort and we can share knowledge.
AKM just notified me that the AK5397 is about to be released. I would hold off for a few weeks until I can make some measurements. Its very promising already.
From the prelim spec:
sample rates to 768 KHz
THD+N 110 dB
SNR 130 dB in mono mode.
It may not need a DSP to do the mono stuff.
Right now I know of several efforts around a measurement grade AD-DA. I need to get them in sync so there is little redundant effort and we can share knowledge.
AKM just notified me that the AK5397 is about to be released. I would hold off for a few weeks until I can make some measurements. Its very promising already.
From the prelim spec:
sample rates to 768 KHz
THD+N 110 dB
SNR 130 dB in mono mode.
It may not need a DSP to do the mono stuff.
Okay well let me know when this all emerges. I'm in the research mode right now while I wait for PCB.
While where on the subject I need to know some specifics about the AKs and I2S in general. I noticed in the schematic for the 5394 EVM board the master clock is always from the on board oscillator. It does allow external master control of the I2S. I assume the ADC always uses the master CLK for conversion and allows transmission of the data from an external master. This makes me curious about how this is all synchronized. If the I2S shift registers are double buffered then sync is never a problem. The question is does the I2S run asynchronously from the convertor or does the master clock have to be synchronized with the I2S master. If it's asynchronous then it simplifies the process. FFT couldn't care less of jitter. It just needs the data intact, bit perfect. Time doesn't matter. ARTA needs a steady stream and imagine other software as well.
The DSP I mention only go to 192kbps. There might be use for the other functions like more sophisticated algorithms for noise reduction. The DSPs can self boot from a serial eeprom using the SPI port. At least the one I mentioned. No uP required. i would have to add switches on the GPIO to switch sample rate with the convertor. The element seem to be locked to a single specified sample rate. I would have to duplicate the signal string for each speed.
The AD dsps look quite cool and would be fun to play with. I'm trying to think of a way of getting the convertors to sample synchronously with the period of the sine or get the DSP to filter complete periods of samples. Then the FFT doesn't need windowing.
Sample rates to 768 KHz at 32 bit puts the miniDSP out of business. That leaves me with a problem of getting it into the PC.
Thank you for the news! It seams that they did some home work...
I suggest that you open a new thread for the AK5397 ADC (if you do not have any none disclose)... also some will pickup this as a DIY 😀
Interesting will be to feed 2 mono channel data into the PC using a two quad 192khz ADAT chained channels 😎 while I did this already for 384Khz using a stereo 192khz using the WDM interface.
Hp
I know we're getting away from 'QA400' but I'm continuing the tangent we're on here.
I have a Parallella board on pre-order that I hope to receive in the coming months, so what I write below I'll be trying with that board. It could equally be done with other Xilinx Zynq boards (Zedboard or microZed) but I wanted to play with the Ephiphany co-processor so ordered the Parallella.
I intend to do an IO board design which stacks to the Parallella Samtec expansion sockets and use this for a DIY measurement/DSP project.
The advantage here is that the processor has FPGA on chip which will allow us (community or me alone - either way) to interface to ADC/DAC hardware with FPGA taking care of any device specific quirks.
- Two SAR ADCs (not sure which one yet 5MSPS 18bit is possible so could certainly be interesting).
- AES/EBU, spdif and Toslink for external DAC/ADC interfaces
- on board Stereo audio ADC / DAC (ESS, Ti or AKM headline parts ... not personally committed to any so much ESS and AKM look most appealing but are both difficult to source in Australia)
- ethernet interface and web interface for control of measurements (IPython Notebook + Audiolazy + bokeh plotting engine)
Not a cheap or 'simple' project but if I get it working could provide a useful tool. IPython Notebooks give an interface similar to Matlab/MathCAD etc and could easily build a library of standardised Notebooks for different types of measurements. This would allow Open Source measurements where the analysis is able to be peer reviewed rather than reliance on 'free' or 'cheap' software where the calculations are obfuscated from the user. Since the i2c/spi comms controlling the ADC/DAC will be in the Parallella a complete measurement config could be saved.
I think this might get us further than QA400 potentially but would require really quite a significant investment of development time.
Thoughts? Is this an idea worthy of a new thread?
Regards,
Chris
I have a Parallella board on pre-order that I hope to receive in the coming months, so what I write below I'll be trying with that board. It could equally be done with other Xilinx Zynq boards (Zedboard or microZed) but I wanted to play with the Ephiphany co-processor so ordered the Parallella.
I intend to do an IO board design which stacks to the Parallella Samtec expansion sockets and use this for a DIY measurement/DSP project.
The advantage here is that the processor has FPGA on chip which will allow us (community or me alone - either way) to interface to ADC/DAC hardware with FPGA taking care of any device specific quirks.
- Two SAR ADCs (not sure which one yet 5MSPS 18bit is possible so could certainly be interesting).
- AES/EBU, spdif and Toslink for external DAC/ADC interfaces
- on board Stereo audio ADC / DAC (ESS, Ti or AKM headline parts ... not personally committed to any so much ESS and AKM look most appealing but are both difficult to source in Australia)
- ethernet interface and web interface for control of measurements (IPython Notebook + Audiolazy + bokeh plotting engine)
Not a cheap or 'simple' project but if I get it working could provide a useful tool. IPython Notebooks give an interface similar to Matlab/MathCAD etc and could easily build a library of standardised Notebooks for different types of measurements. This would allow Open Source measurements where the analysis is able to be peer reviewed rather than reliance on 'free' or 'cheap' software where the calculations are obfuscated from the user. Since the i2c/spi comms controlling the ADC/DAC will be in the Parallella a complete measurement config could be saved.
I think this might get us further than QA400 potentially but would require really quite a significant investment of development time.
Thoughts? Is this an idea worthy of a new thread?
Regards,
Chris
If you have the time. That could take many years.
For the parts. A DIY relay could land them on your doorstep.
I have found that a universal audio tester doesn't really work. It makes more sense to work back from what you want to know through what you need to test for to the hardware necessary.
Measuring acoustics is a way different problem from measuring electronics, in several dimensions. Also some types of tests that look so promising eventually yield very little.
The QA400 is a clear and concise approach to quickly measuring a number of basic parameters. I think an ideal next step would be an RMAA like sequence of tests that will provide a quick bill of health of an electronic system. Its really quite good at measuring distortion down to -100 dB (that was state of the art not long ago). It will also measure frequency response and SNR.
I find a traditional bench instrument with a scope attached is the quickest way to dial in an amp or many similar types of optimizations and troubleshooting. One of the reasons I don't have an AP on my bench. No room for a PC there.
Measuring acoustics is a way different problem from measuring electronics, in several dimensions. Also some types of tests that look so promising eventually yield very little.
The QA400 is a clear and concise approach to quickly measuring a number of basic parameters. I think an ideal next step would be an RMAA like sequence of tests that will provide a quick bill of health of an electronic system. Its really quite good at measuring distortion down to -100 dB (that was state of the art not long ago). It will also measure frequency response and SNR.
I find a traditional bench instrument with a scope attached is the quickest way to dial in an amp or many similar types of optimizations and troubleshooting. One of the reasons I don't have an AP on my bench. No room for a PC there.