Open-source USB interface: Audio Widget - Page 157 - 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 30th May 2012, 01:15 PM   #1561
1audio is offline 1audio  United States
diyAudio Member
 
Join Date: Mar 2004
Location: SF Bay Area
Blog Entries: 3
Quote:
Originally Posted by borges View Post
That looks like a cool chip! With one we have I2S and MCLK. In addition a few GPIO lines are needed, but they should be able to go over cheaper and slower isolators.

The GPIO lines I think of are:
- Filter select
- VBUS_EN
- MCLK_P48_N441
- UART TX & RX (it's nice to have some comms link)
- Maybe an interrupt line

Any more lines needed? I imagine making a go-between board between the USB-I2S module and the analog board where the bare minimum of IO lines are isolated and power is inserted.

BÝrge
Add I2C to your list.

The jitter on the isolator is an issue (100 pS) so its not really suitable as a clock source for the DAC but may be OK if the clocks are on the DAC side. I would latch the data after the isolator on the DAC side just to make it as clean as possible.
__________________
Demian Martin
Product Design Services
  Reply With Quote
Old 30th May 2012, 01:24 PM   #1562
diyAudio Member
 
Join Date: Apr 2011
1. For the MCLK, the clock source is on the DAC side and only the divided (and maybe latched) clock is passed through the isolator to the uC side. So the 100ps jitter is not an issue.

2. For I2C, you need a bi-directional isolator, such as the ADuM1250, which we have had good results with in another project.

Alex
  Reply With Quote
Old 30th May 2012, 08:00 PM   #1563
starn02 is offline starn02  Italy
diyAudio Member
 
Join Date: Jul 2005
Location: Italy
Default I2S clocks on the AB 1.1

Hi everybody,
I'm trying to understand better the structure of the I2S interfacing on the AB 1.1, and the inner workings of I2S as implemented on the UC3A3.

Reading the Atmel docs, looking at the code, and seeing the schematics of AB 1.1 I think I ve understood that:

- I2S on the UC3A3 has the limitation that the main clock of the CPU must be synchronous with the clock that drives the SSC module that implements I2C (at least this is what I can understand from the phrase: "Because the master clock must be synchronous to the sample rate both clock sources to the generic clock and to the SSC module must have the same source"

- on the AB 1.1 there are 2 clocks (24.576 and 22.5792 Mhz, the Golledge clocks), one of the two is selected (as a function of the desired sampling frequency, the biggest for 48K and multiples and the other for 44.1K and multiples)

- the selected clock is sent DIRECTLY to the DAC chip, and a divided by 2 version is sent to the CPU (or better, to the power manager, that incorporates PLLs and dividers to create an internal clock to be used by the I2S logic and the CPU).

Now, if I'm not mistaken, the I2S clock is OUTPUT by the UC3 but is unused (the DAC chip is fed directly by the selected clock), while the other signals, mainly LRCLK are generated by the I2S module with internal dividers and counters.

My doubt is as follows:
aren't there any jitter problems on such signals?
The main clock to the DAC comes directly from the high precision Golledge clocks, and that's OK, but LRCLK and SDATA come from the UC3, and so are potentially contamined by internal digital noise ... the UC3 has lots of digital circuitry, with many many different clocks ...

My question (to the experts) is as follows: is it possible on the UC3 to drive the I2S clock from the external? Is the sync between the "generic clock" and the clock of I2S really mandatory?

Moreover, what's the speed of the CPU in this situation? Does it change with selected clock speed? I see in the code that, depending from the desired sampling frequency, the "generic clock" is something between about 3 and 12 Mhz ... is this the speed at which the chip runs while playing?

Last edited by starn02; 30th May 2012 at 08:07 PM. Reason: Corrections
  Reply With Quote
Old 30th May 2012, 09:25 PM   #1564
1audio is offline 1audio  United States
diyAudio Member
 
Join Date: Mar 2004
Location: SF Bay Area
Blog Entries: 3
For the internal of the Atmel Alex would know best. On I2S though I can say it all depends. . . Some DACs, most Delta Sigma designs are completely drivin by the master clock and as long as the setup times are met for the other signals everything will be fine. However I would actually use a latch (e.g. LS373) run from the master clock with a clean supply until proven it doesn't help. its almost free to do.

If the DAC chip is different (ladder dac for example) the bit clock or word clock become much more critical in their timing. The latch will fix that.
__________________
Demian Martin
Product Design Services
  Reply With Quote
Old 31st May 2012, 03:19 AM   #1565
diyAudio Member
 
Join Date: Apr 2011
Quote:
Originally Posted by starn02 View Post

- I2S on the UC3A3 has the limitation that the main clock of the CPU must be synchronous with the clock that drives the SSC module that implements I2C (at least this is what I can understand from the phrase: "Because the master clock must be synchronous to the sample rate both clock sources to the generic clock and to the SSC module must have the same source"
The Atmel phrase is correct. The SSC needs to be clocked by a source that is synchronous with the DAC MCLK so that the i2s signals generated by the SSC are ultimately synchronous with the DAC for synchronous clocking.

However, the *main* clock of the cpu need NOT be synchronous, and in fact is not. We need cpu to be clocked by a 12Mhz crystal (OSC0) so that it can generate the USB clock for HIGH speed USB communication with the host.

[QUTOE]

- on the AB 1.1 there are 2 clocks (24.576 and 22.5792 Mhz, the Golledge clocks), one of the two is selected (as a function of the desired sampling frequency, the biggest for 48K and multiples and the other for 44.1K and multiples)

- the selected clock is sent DIRECTLY to the DAC chip, and a divided by 2 version is sent to the CPU (or better, to the power manager, that incorporates PLLs and dividers to create an internal clock to be used by the I2S logic and the CPU).

Now, if I'm not mistaken, the I2S clock is OUTPUT by the UC3 but is unused (the DAC chip is fed directly by the selected clock), while the other signals, mainly LRCLK are generated by the I2S module with internal dividers and counters.

[/QUOTE]

The i2s clock/data are output by the SSC and to the DAC chip: TX_DATA, TX_CLOCK, TX_LRCK.

The DAC chip only gets the MCLK directly from the Golledge clocks.

Quote:
My doubt is as follows:
aren't there any jitter problems on such signals?
The main clock to the DAC comes directly from the high precision Golledge clocks, and that's OK, but LRCLK and SDATA come from the UC3, and so are potentially contamined by internal digital noise ... the UC3 has lots of digital circuitry, with many many different clocks ...
As 1Audio has explained, it depends on the DAC. For the DAC's that we are using, the MCLK has to have the lowest jitter. But the i2s clocks (TX_CLOCK, LRCLK) can tolerate much higher jitter without adverse effects on the SQ.

In fact, there is another subtle effect. High jitter in the i2s clocks, especially if it is uncorrelated, may have a "spread spectrum" effect such that there may be a reduction of radiated noise from the uC side to the analog circuitry in the DAC side.

Quote:

My question (to the experts) is as follows: is it possible on the UC3 to drive the I2S clock from the external? Is the sync between the "generic clock" and the clock of I2S really mandatory?
The i2s clocks and data are generated by the SSC. This ensures that the setup and data validity times are completely controlled by the SSC and therefore within the i2s specs.

It is possible to generate i2s clocks "externally", but you will probably need to use an FPGA, and you need to have another channel to transfer the audio data from the uC to the FPGA (eg memory mapped transfer etc.) Then you also have the problem of controlling the jitter of the FPGA, and handling the digital noise generated by the FPGA (and its PSU) itself etc. Even with "external" clocking, you will also need to use opto or magneto isolation. The isolation will generate jitter as well.

So ultimately one has to consider what you are trying to achieve wrt to jitter in the the i2s clocks.

My hunch is that for some DAC's, the MCLK is the key. The i2s is just for transferring the data across, and jitter in the i2s clocks does not impair SQ (and in fact may improve SQ because of the spread spectrum effect).

Alex
  Reply With Quote
Old 31st May 2012, 06:12 AM   #1566
starn02 is offline starn02  Italy
diyAudio Member
 
Join Date: Jul 2005
Location: Italy
Hi people,
thank you for your replies, the clarifications are very useful.

So, if I understand well, the CPU is running from the clock on OSC0 (connected to a 12 Mhz quartz) and so it's independent from the selected audio clock.
Is the CPU running at full speed all the time ( 66 Mhz)?
I was trying to understand if there was a change in temperature of the chip with different audio sample rates, and my impression was that temperature was invariant.

Another small question, if possible: what's the meaning of the two (red and green) small leds next to the CPU?

I suppose they are a sort of feedback about how much full are the sample buffers, but what's exactly the meaning and should they be lit or not during normal playback?

Thank you again for all your support.
  Reply With Quote
Old 31st May 2012, 06:30 AM   #1567
diyAudio Member
 
Join Date: Apr 2011
1. The cpu is at 66Mhz after statup


2 the red and.green.leds toggle when the feedback rate is increased or decreased respectively. They shpuld blink when u first playback atba particular sampling rate and after a few milliseconds to seconds (depending on the clock discrepency between the host usb and the widger XO), settle to a locked atate, where one if the leds will.blink once every minute or so.

Alex
  Reply With Quote
Old 31st May 2012, 12:55 PM   #1568
starn02 is offline starn02  Italy
diyAudio Member
 
Join Date: Jul 2005
Location: Italy
Thank you again, Alex.

Sometimes on my board at 96Khz, or 192 khz, I have both leds on .... Sometimes they change, maybe initially all off, but I got several times in the situation of both ON ... Is this normal?
Audio seems OK, no audible gaps or distortions ...
  Reply With Quote
Old 31st May 2012, 02:24 PM   #1569
diyAudio Member
 
Join Date: Apr 2011
Yes normal. As I said, the led's TOGGLE. So sometimes both are toggled to the on state (both on) and sometimes both are toggled to the off state (both off) etc.

Alex
  Reply With Quote
Old 31st May 2012, 06:40 PM   #1570
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
Quote:
Originally Posted by alexlee188 View Post
In fact, there is another subtle effect. High jitter in the i2s clocks, especially if it is uncorrelated, may have a "spread spectrum" effect such that there may be a reduction of radiated noise from the uC side to the analog circuitry in the DAC side.
Quote:
My hunch is that for some DAC's, the MCLK is the key. The i2s is just for transferring the data across, and jitter in the i2s clocks does not impair SQ (and in fact may improve SQ because of the spread spectrum effect).

Alex
I'm glad that you mentioned spread spectrum. I see many new clock generator chips that purposefully create jitter with the goal of reducing the amount of interference at the clock frequency by spreading the spectrum, such that there is a much lower power spike at the center frequency. This is great for non-audio clocks, because it reduces interference with other electronics that might be nearby.

What I wonder is how you can mix spread spectrum clocks with a low-jitter audio sample clock. How do you prevent the data from getting behind the clock? As I understand it, the data must be sent (slightly) ahead of the clock so that random variations in propagation delay over different serial lines (4-wire, etc) do not cause problems. When the clock latches the data, you don't want indeterminate data.

Can you explain how spread spectrum clocks can be used in a digital audio system where a low-jitter clock is being used as the master? (and I hope this isn't off-topic for the Audio Widget)
  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
Async 192Khz USB - the SDR-Widget collaborative project SunRa PC Based 5 26th April 2011 06:38 PM
usb audio interface david12 Equipment & Tools 14 10th October 2010 02:58 AM
Cheap Audio Interface (USB?) to PC agm2003 Instruments and Amps 11 16th September 2007 07:48 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
USB Interface Perfect?- Computer Audio fmak Digital Source 3 4th December 2004 10:24 PM


New To Site? Need Help?

All times are GMT. The time now is 09:33 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