Can anybody describe a little how the connection between the Atmel MCU and the es9023 is implemented?
From the schematics I see (if I'm not mistaken) that the clock to the es9023 comes directly from crystals, while the other signals (data, LRClock and SCLK) come from the MCU .... What about timing synchronization between the clock and the SSC the MCU ? Aren't there jitter or delay problems between the signals?
From the schematics I see (if I'm not mistaken) that the clock to the es9023 comes directly from crystals, while the other signals (data, LRClock and SCLK) come from the MCU .... What about timing synchronization between the clock and the SSC the MCU ? Aren't there jitter or delay problems between the signals?
Please follow the link from my signature and look at the module schematics. L1006 and L1007 are between USB VBUS/GND and those on the board.
The components are 0603. If you suggest any alternative components, please let me know! The ones used I copied from an unrelated USB design.
Oh, and if the sch/layout could be improved on, let us know about that too.
Børge
OK. This is a brief description and discussion of the clock signals in the audio-widget. If anyone is interested in the details and rationale and scope tracings etc., join the sdr-widget and audio-widget Google groups and search the archives 
The most important ultra low jitter clock is the MCLK to the DAC. This is achieved in the AW by clocking the ES9023 directly with either the 24.576Mhz or the 22.5792Mhz XO, selectable by the uC.
The i2S clock inputs to the DAC, ie SCLK and LRCK, has to be *synchronous* to the MCLK, but the phase relationships and jitter tolerances are much more flexible (as we have found out). This is because the SCLK/LRCK are used to clock digital data into the DAC's internal registers. How and when the data is "clocked" out by the sigma delta demodulator is governed by the MCLK.
To ensure that SCLK/LRCK are synchronous to MCLK, they are derived from the MCLK.
The MCLK is divided by 2 by a flip-flop (which incidentally also acts as a buffer between the MCLK/DAC circuitary and the digital uC circuitary), and fed into the Osc 1 input of the Atmel uC.
Using the uC's programmable generic clock dividers and the SSC's programmable dividers, the correct SCLK/LRCK signals and the corresponding SDATA are generated based on the i2S protocol timing and rise/fall edges etc.
You will not be able to do this with some DAC's that do not have a MCLK, and relies on the SCLK for precise timing.
Alex
The most important ultra low jitter clock is the MCLK to the DAC. This is achieved in the AW by clocking the ES9023 directly with either the 24.576Mhz or the 22.5792Mhz XO, selectable by the uC.
The i2S clock inputs to the DAC, ie SCLK and LRCK, has to be *synchronous* to the MCLK, but the phase relationships and jitter tolerances are much more flexible (as we have found out). This is because the SCLK/LRCK are used to clock digital data into the DAC's internal registers. How and when the data is "clocked" out by the sigma delta demodulator is governed by the MCLK.
To ensure that SCLK/LRCK are synchronous to MCLK, they are derived from the MCLK.
The MCLK is divided by 2 by a flip-flop (which incidentally also acts as a buffer between the MCLK/DAC circuitary and the digital uC circuitary), and fed into the Osc 1 input of the Atmel uC.
Using the uC's programmable generic clock dividers and the SSC's programmable dividers, the correct SCLK/LRCK signals and the corresponding SDATA are generated based on the i2S protocol timing and rise/fall edges etc.
You will not be able to do this with some DAC's that do not have a MCLK, and relies on the SCLK for precise timing.
Alex
It looks like the "Sabre" DAC designs are rated "top secret" by ESS. Apparently no one but ESS has more than those two pages.
Only for the old ES9008 a somewhat more detailed data-sheet have been leaked out. You may want to refer to that: I guess there have been not too much "external" changes. Actually, the 9023 may even be directly derived from it.
Have a look at this thread: http://www.diyaudio.com/forums/digital-line-level/117238-ess-sabre-reference-dac-8-channel.html
(and in particular pay attention to the posts from "dusfor99" alias Dustin Foreman, which is one of the designers of the "Sabre" DAC).
Last edited:
I'm voting for TI and Wolfson. They make sense of support, samples, datasheets etc.
I say it's better to use a good DAC we can utilize fully, than an ESS device where we are fumbling around in the dark. The ES9023 is a simple device. The ES9018 has IVC and PSU needs I don't wish to experiment around. Since they, for all practical purposes, are not documented, it's no fun working with that chip.
Børge
I say it's better to use a good DAC we can utilize fully, than an ESS device where we are fumbling around in the dark. The ES9023 is a simple device. The ES9018 has IVC and PSU needs I don't wish to experiment around. Since they, for all practical purposes, are not documented, it's no fun working with that chip.
Børge
The clock from the XOs branches in two. One branch goes directly to the DAC, the other to a divice-by-two flip-flop and into the MCU. The MCU can't handle the high 22-24MHz MCLK frequency directly.
The MCU uses I2S to talk to the DAC. You need both schematics in front of you to trace through the module interface.
It so happens that the bit clock of the I2S bus is the same signal as the divided-by-two MCLK which enters the MCU. This gives enough ticks for stereo 32-bit data at 192. Bumper-to-bumper I2S can be risky, so 24-bit data to the DACs is preferable.
Børge
Yes, you can latch onto the half-moon pads on the edge of the module. There's no dedicated I2S header. (Hint to self for revised layout...)
Børge
I had skimmed this before, but i hadnt noticed this very nice and rather logical description of the intrinsic audible effect of jitter
ESS said:
Wouldn't it be possible to configure the I2S so that we feed the clock to the bit clock of the I2S bus instead of letting this signal pass through all the MCU? I guess that the signal is formally the same, but in practice in the actual setup we get an output bit clock that is much less "clean" with respect to the clock coming from the divider ...
I believe so, but it's better to let the MCU's shift registers manage set-up and hold times. Besides, the DAC requires clocks in the 22-24MHz range whereas the MCU copes with 11-12. I don't trust a flip-flop to not introduce jitter, and XOs at 11.2896/12.288MHz aren't compatible with the two highest sample rates.
The MCLK passes directly to the DAC anyway. In a perfectly logical world, MCLK clocks the sigma-delta modulator and current switches.
The PCM1704 is a different story. This DAC doesn't have an MCLK input pin. Instead this multibit converter does 24-bit parallel latching on the 4th (or 2nd?) bit clock tick after word clock. So in that design, the bit clock comes straight from the XO and everything else slaves it.
Børge
Hi guys,
here's a thread to the AVR forum where I asked what has to be done electrically in order to use the USB-I2S module with a mains powered DAC.
View topic - USB self powered :: AVR Freaks
Merry Christmas everyone!
Børge
here's a thread to the AVR forum where I asked what has to be done electrically in order to use the USB-I2S module with a mains powered DAC.
View topic - USB self powered :: AVR Freaks
Merry Christmas everyone!
Børge
Now it's Christmas - if we have been nice we can have whatever we want...
For a starter - Yes - I want a 24/192 driver to a reasonable cost. If not I will do whatever it takes to help writing one and it will be free - sorry - no money in this one.
But now, why put this effort in something that will be the standard offering in a short while? The frontbreatchers is on 32/384 or whatever now. So the free (as in no pay) driver for the audio-widget should have atleast the stubs built in for the future. The model should be likely as free - pick whatever - and write some code (as our best knowledge and support on everyones time they want to put into the project) and you be all set to use whatever MCU or technology you desire as long it plays with these ideas. I couldn't write terms since I'm have no idea of the others view of where the audio-widget is heading in commercial terms.
And of course I beg you all a very Merry Christmas!
Brgds
For a starter - Yes - I want a 24/192 driver to a reasonable cost. If not I will do whatever it takes to help writing one and it will be free - sorry - no money in this one.
But now, why put this effort in something that will be the standard offering in a short while? The frontbreatchers is on 32/384 or whatever now. So the free (as in no pay) driver for the audio-widget should have atleast the stubs built in for the future. The model should be likely as free - pick whatever - and write some code (as our best knowledge and support on everyones time they want to put into the project) and you be all set to use whatever MCU or technology you desire as long it plays with these ideas. I couldn't write terms since I'm have no idea of the others view of where the audio-widget is heading in commercial terms.
And of course I beg you all a very Merry Christmas!
Brgds
Last edited:
Hi guys,
I miss the complete datasheet of ES9023, so I wonder what's the reason behind the choices of capacitor around it.
I see a generic approach based on a parallel of: 4n7, 1u, 10u, 15u ... some of them installed, some not, for AVCC, VREG, NEG e between CN and CP.
I understand that some of the places on the board are simply for testing, but are there limits for some of the pins?
For charge pump capacitor (which I suppose is the one between CN and CP) are there suggested or limit values? Actually I have 1u in parallel with 4n7. Can I use also 15u?
And the 4n7 capacitors are to be considered as bypass? Why not the more common value of 100nF?
I miss the complete datasheet of ES9023, so I wonder what's the reason behind the choices of capacitor around it.
I see a generic approach based on a parallel of: 4n7, 1u, 10u, 15u ... some of them installed, some not, for AVCC, VREG, NEG e between CN and CP.
I understand that some of the places on the board are simply for testing, but are there limits for some of the pins?
For charge pump capacitor (which I suppose is the one between CN and CP) are there suggested or limit values? Actually I have 1u in parallel with 4n7. Can I use also 15u?
And the 4n7 capacitors are to be considered as bypass? Why not the more common value of 100nF?
I believe Alex played with the caps according to some older posts in the google audio widget group. Fo myself - I haven't even given them a thought since the driver comes first as I see it. My next move is to read a book or two about windows drivers during my winter vacation. If I can find any until tuesday!
Now the only book I found won't be shipped fast enought. Does anyone know about a bookshop in Miami who might sell books from MS Press? Do they have the book about drivers?
Brgds
Last edited: