XMOS-based Asynchronous USB to I2S interface - Page 81 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 24th May 2012, 05:10 PM   #801
diyAudio Member
 
Join Date: Jul 2010
Default Thanks!

Quote:
Originally Posted by 1audio View Post
The Wavecrest is a useful tool but not the best for this type of measurement. You are looking for the phase noise spectrum to get any real information. That is very closely related to the plots published in the Stereophile. The Wavecrest looks at the cycle to cycle spread of the master clock and essentially analyses its variations. It also measures across the entire hf spectrum. Its much less sensitive to low frequency variations however.

The most accepted way to measure the phase noise of the clock is using a phase locked reference clock and a double balanced mixer along with a low noise amplifier etc. into an audio spectrum analyzer. You need a really good reference clock, which can be difficult to find or really expensive. There are several tools for converting the measured phase noise into jitter. Phase noise above 2X the sample rate will not contribute to jitter in the output. There are a lot of questions about the audibility of low frequency phase noise since its contribution is attenuated by the process and peoples sensitivity to pitch modulation is well documented (from tape and disk studies) and way higher that anything from these processes.

The important thing to look for is deterministic jitter, the specific identifiable tones that come through. These can be much higher than the random jitter and may be audible at much lower levels.

While its interesting to see what jitter is in the clock its more meaningful to see what comes through to the output of the system, since this is the cumulative effects of all the jitter mechanisms upstream. ASRC's can remove some jitter problems but they will also permanently imbed others into the stream.
Demian. So considering the WaveIO's I2S output in isolation, the important info to know would be the phase noise of the masterclock signal, correct? It appears that few folks are going to be set up to measure this very precisely.

Then for an entire DAC, looking at the analog output spectrum (ala JA's Stereophile measurements) is what will be most telling about jitter artifacts which will/may affect perceived sonics?

I have never really heard a good explanation why ASRCs may be "bad", but subjectively it is my experience that I do not "like" them. Hence I run my ESS based DAC with the onboard ASRC and DPLL defeated and provide as good a masterclock signal as I can (Crystek CCHD with as clean a power supply as possible).
  Reply With Quote
Old 24th May 2012, 09:33 PM   #802
JensH is offline JensH  Denmark
diyAudio Member
 
Join Date: Jul 2009
@ Lorien

I have followed this thread with interest for quite some time now. I have not read all the posts though, so maybe I have missed some details.

Have you considered to move the clock oscillators to the isolated output side of the circuit? I assume that you are using the IL715 isolator from NVE. If you use the IL717 + a low cost (slow) optocoupler to select the clock, I think you could feed the very clean clock from the oscillators directly to the DAC. And the XMOS chip would still get a low jitter clock (but not a super low jitter) through the "return channel" of the IL717, which I assume will be perfectly OK for that purpose. You could of course also use the IL261. Then you would not need an optocoupler.
I think something similar was hinted at in post #382, without being specific about the details.

I think that with this arrangement, you could achieve the optimum jitter level for the master clock, only limited by the clock oscillator performance. If a low jitter on the bit clock is needed it will of course be necessary to synchronize this to the master clock with a flip-flop.

If there is no supply on the output side there will of course not be a master clock either. I don't know if that could be a problem? If it starts normal operation when the clock becomes available without locking up in some way, I guess it should be OK.

I think that such a design could be quite interesting.
  Reply With Quote
Old 25th May 2012, 05:30 AM   #803
1audio is offline 1audio  United States
diyAudio Member
 
Join Date: Mar 2004
Location: SF Bay Area
Blog Entries: 3
Quote:
Originally Posted by barrows View Post
Demian. So considering the WaveIO's I2S output in isolation, the important info to know would be the phase noise of the masterclock signal, correct? It appears that few folks are going to be set up to measure this very precisely.
Very few indeed and the results may not translate into a real product. Connections and implementation make it all very difficult.
Also, depending on the DAC chip Master clock may not be the one that matters.


Quote:
Originally Posted by barrows View Post
Then for an entire DAC, looking at the analog output spectrum (ala JA's Stereophile measurements) is what will be most telling about jitter artifacts which will/may affect perceived sonics?
Its marginal to point at a jitter spectrum and pronounce what will be audible. Cleaner (fewer spurs) is better, how much so is not clear.

Quote:
Originally Posted by barrows View Post
I have never really heard a good explanation why ASRCs may be "bad", but subjectively it is my experience that I do not "like" them. Hence I run my ESS based DAC with the onboard ASRC and DPLL defeated and provide as good a masterclock signal as I can (Crystek CCHD with as clean a power supply as possible).
Personally I would not add an ASRC unless there were a need for it. In an async USB interface its redundant.
__________________
Demian Martin
Product Design Services
  Reply With Quote
Old 25th May 2012, 06:08 AM   #804
diyAudio Member
 
Join Date: Sep 2005
Send a message via MSN to audiodesign Send a message via Skype™ to audiodesign
With some friends, I have organized a listening session to compare the 2 outputs of the XMOS module, I2S isolated and coax.

The I2S isolated, also if used with common ground, like my schematic, is much better than coax and I don't know why.

Probably the IL715 isolator clear the I2S signals or reduce the impedance.

In the future I will do the same test with other audio system.
  Reply With Quote
Old 25th May 2012, 12:26 PM   #805
Telstar is offline Telstar  Italy
diyAudio Member
 
Join Date: Dec 2007
Location: Italy
Quote:
Originally Posted by audiodesign View Post
With some friends, I have organized a listening session to compare the 2 outputs of the XMOS module, I2S isolated and coax.

The I2S isolated, also if used with common ground, like my schematic, is much better than coax and I don't know why.
Tnx Andrea i was waiting for this test.
How do you power the waveio, the computer and the dac? The answer is there.
__________________
"The total harmonic distortion is not a measure of the degree of distastefulness to the listener and it is recommended that its use should be discontinued." D. Masa, 1938
  Reply With Quote
Old 25th May 2012, 02:20 PM   #806
diyAudio Member
 
Join Date: Jul 2010
Default My understanding...

Is that most SPDIF receivers are poor perfromers at best, adding 200-300 pS of jitter. The Coax output of the WaveIO is transfomrer isolated, right? So I expect that the differences you note are down to the improvement of avoiding SPDIF. My experience has been that well implemented I2S direct to the DAC chip will outperform SPDIF every time.
  Reply With Quote
Old 25th May 2012, 05:13 PM   #807
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
Quote:
Originally Posted by barrows View Post
I have never really heard a good explanation why ASRCs may be "bad", but subjectively it is my experience that I do not "like" them.
I'll make an attempt to explain it.

The input to an ASRC is assumed to be standard digital audio. The exact PCM samples are encoded in the bits, while the required DAC timing is assumed to be a "perfect" clock. You really cannot assume anything but a perfect clock because there is no additional information in the bit stream to describe any other kind of clock.

Unfortunately, what ASRC does is look at the timing of the incoming bit stream, compare it to the local DAC clock, and then alter the PCM samples to fit. In most cases, this seems to be a bad way to handle things because the incoming bit stream is a bad indicator of timing, and in the case of async USB it's not any kind of indicator. What happens is that all of the bad timing of the bit stream is "printed" onto the PCM samples, which then makes it more audible, and impossible to correct.

I think that there is only one valid application for ASRC, and that's where you do not have any control over the incoming data rate and do not have the ability to PLL the DAC clock to match. In those situations, you'd end up with a pop every time the input and output clocks miss a sample or repeat a sample. The cure for this pop is ASRC to stretch or squish the incoming data so that it fits the output DAC clock.

Getting back to Async USB, there's no need for ASRC, because the DAC clock can simply be used as a control signal to throttle the PCM sample data coming from the computer. Whether it's too slow or too fast, the DAC should not click because the computer will adjust automatically, provided the USB Device firmware and Host drivers are all communicating to specifications.

To reiterate, digital audio always involves separate clock rates on the sending and receiving devices which must be reconciled. There are four ways (that I can think of) to match the clock rates.
1) Distribute Word Clock to both devices so that they use the same clock.
2) Use bidirectional communications (FireWire Audio, Async USB, etc.) to force the sending device to match its data rate to the DAC.
3) Use a PLL to force the receiving device to match its DAC clock rate to the incoming data.
4) Use ASRC to recreate the (hopefully) appropriate waveform without changing either the sending or receiving clock rates.

In my opinion, those four options are listed in decreasing order of quality. And, by the way, SPDIF cannot handle option 2 because it is a unidirectional link. Since Word Clock is a bit complicated for the average audio person outside a studio, Async USB (or equivalent) becomes the first choice. In all cases, I see ASRC as a last resort when nothing else can possibly work.

Last edited by rsdio; 25th May 2012 at 05:15 PM.
  Reply With Quote
Old 25th May 2012, 06:08 PM   #808
1audio is offline 1audio  United States
diyAudio Member
 
Join Date: Mar 2004
Location: SF Bay Area
Blog Entries: 3
The description of the ASRC is close but not quite complete.
The ASRC has no knowledge of the actual intended rate of the incoming data. Whatever it is is assumed to be right (asynchronous). The output is the target clock. What it does is create a model for the analog signal that the input would create with a low pass function based on the input rate (and the output rate). It can interpolate and remove some short term stuff but below a certain rate of change it morphs and does not remove it any more. The interpolated audio is encoded into samples and passed to the output.

They have many uses but are a real compromise if not necessary and a really good one (like the Berkeley Audio implementation) uses a fair amount of processor.

There is also the synchronous sample rate converter which knows the input rate and the output rate and can use a more specific and optimized interpolation and filtering process. These are what are tested here: SRC Comparisons . The tests will give some insights into the challenges, and those are running on high powered PC's and don't need to deal with odd sample rates.
__________________
Demian Martin
Product Design Services
  Reply With Quote
Old 25th May 2012, 06:25 PM   #809
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
Quote:
Originally Posted by 1audio View Post
The ASRC has no knowledge of the actual intended rate of the incoming data. Whatever it is is assumed to be right (asynchronous).
As I tried to point out, the ASRC can make one assumption: That the actual intended rate of the incoming data is supposed to be aligned to a "perfect" or ideal clock - in other words, I don't think it's possible to assume that the incoming data has correctable jitter, because there is no communication channel available to describe any such jitter in a way that would allow it to be corrected. Therefore, the only logical remaining options are that the clock is perfect, or that it has uncorrectable jitter. Either way, jitter is not going to be corrected or improved.

You are correct, of course, that the incoming data's nominal rate, ignoring jitter, is completely unknown by the ASRC. No matter how long the ASRC monitors the input, there is no guarantee that future samples will arrive at the average rate seen so far.
  Reply With Quote
Old 25th May 2012, 07:14 PM   #810
Telstar is offline Telstar  Italy
diyAudio Member
 
Join Date: Dec 2007
Location: Italy
Quote:
Originally Posted by barrows View Post
Is that most SPDIF receivers are poor perfromers at best, adding 200-300 pS of jitter. The Coax output of the WaveIO is transfomrer isolated, right? So I expect that the differences you note are down to the improvement of avoiding SPDIF. My experience has been that well implemented I2S direct to the DAC chip will outperform SPDIF every time.
He compared i2s outputs only, one is i2s with mini-coax connectors (see picture of the board) and the other is i2s with pins isolated with a nve chip, which is a GMR. It's not known how much jitter this isolator adds.

It is obvious that spdfi would be inferior.
__________________
"The total harmonic distortion is not a measure of the degree of distastefulness to the listener and it is recommended that its use should be discontinued." D. Masa, 1938
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
exaU2I - Multi-Channel Asynchronous USB to I2S Interface exa065 exaDevices 1357 3rd March 2014 09:51 PM
Introducing miniStreamer: Native 24/96 USB to I2S / SPDIF interface minidsp miniDSP 39 6th January 2014 12:00 AM
Ultimate USB to I2S interface sampler Digital Source 206 30th January 2012 04:45 PM
Is it possible to develop a ASIO driver for PCM2900 based USB Audio interface? cxhawk Digital Source 7 3rd December 2010 03:30 PM
interface I2S with USB mermoz Digital Source 0 21st February 2003 11:34 AM


New To Site? Need Help?

All times are GMT. The time now is 02:20 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2