Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

[qusp]

i2s fifo buffer (finished and available)
spdif board (finished and available)
dual clock board (finished and available)
battery management board (finished and available)
isolator board (next GB I think)
Si570 multi frequency Clock board (nearing end of development, ready for next GB I think)
PCM daughterboard and level-shifter for NOS dacs (nearing end of development, but not yet available)
u.fl adapters (available)
Clock adapters (available)

 

[Popolvár]

Si570 interest list:

1. bigpandahk
2. tagheuer
3. hochopeper
4. qusp (of course)
5. AR2 - definitely!
6. wktk_smile
7. hirez69
8. CeeVee - you bet!
9. number9
10. analog_sa - GB maniac
11. edbk
12. atom6422
13. misterrogers X2 - Of Course!
14. NicMac - as usual!
15. Zoran
16. PET-240
17. Coolhead
18. Slartibartfasst
19. SYklab
20. Regland
21. Neb001
22. SPWONG
23. Greg Stewart (also of course!)
24. Vitalica
25. spm
26. Fridrik
27. ccliu
28. makumba1966
29. lindamar
30. Finaxe
31. Odysseas x2
32. palmito
33. crazikid
34. deanoUK
35. Julf
36. DUC985
37. rsotirov
38. kvl
39. bkdog
40. necplusultra
41. Nikola Krivorov X2
42. nvduybom
43. Popolvar

 

[Fridrik]

Low noise\ripple supply

Hi, Just to say your are no fun guys ;-). you are working to fast and specialy Ian
Preparing for the arrival of my Fifo I was shopping for a nice LDO regulator to replace a LM7805 and a LM2937ET-3.3 on my DUAL Mono PCM1794A DAC board. Browsing on the TI site I saw the TPS7A4700 LDO what a nice chip: good specs (1A), simple design but wait I saw it somewhere before .... hum Oh no not in the fifo thread ;-)

Ian any chances your include the TPS7A4700 PCB in GB4 ?

So back in lazy mode for now ;-)

 

[iancanada]

Hi, Just to say your are no fun guys ;-). you are working to fast and specialy Ian
Preparing for the arrival of my Fifo I was shopping for a nice LDO regulator to replace a LM7805 and a LM2937ET-3.3 on my DUAL Mono PCM1794A DAC board. Browsing on the TI site I saw the TPS7A4700 LDO what a nice chip: good specs (1A), simple design but wait I saw it somewhere before .... hum Oh no not in the fifo thread ;-)

Ian any chances your include the TPS7A4700 PCB in GB4 ?

So back in lazy mode for now ;-)

TPS7A4700 reg board is under evaluation now. I'll include it in GBIV if I'm satisfactory with it.

Thanks,

Ian

 

[iancanada]

Inversed MCLK for ESS9018 in asynchronous mode

glt mentioned that inversed mclk would be better for ESS8018 running at sync mode. I read the ESS application note, it really make sense.

I think we need include this feature into the Si570 clock board Ver3.0.

Here I attached the waveform of I2S with normal MCLK and inversed MCLK. The difference on timing in between is very clear. I’ll do some real measurement on this issue later on.

Ian

 

[glt]

Hi Ian,

Although I may be wrongly getting the credit for "mentioning it", I don't understand what you are implying regarding the timing "making sense". could you explain?

And thanks for moving the state of the art forward and benefiting us in the process...

 

[iancanada]

According to this app note: http://esstech.com/PDF/Application_Note_Component_Selection_and_PCB_Layout.pdf on page 5:

"If operating with a synchronous MCLK, it is recommended to use an inverted MCLK. The inverted synchronous MCLK ensures that the Sabre noise is as low as possible."

Hi Ian,

Although I may be wrongly getting the credit for "mentioning it", I don't understand what you are implying regarding the timing "making sense". could you explain?

And thanks for moving the state of the art forward and benefiting us in the process...

Thanks glt for the good suggestion. This issue might be connected to ESS9018 internal ASRC architecture and timing. As ESS application note recommended a inverted MCLK to ensure a lower noise at sync mode, I think 9018 was optimized to the inverted MCLK. I'll give a try on Si570 clock board.

Ian

 

[iancanada]

Hi Ian,

Although I may be wrongly getting the credit for "mentioning it", I don't understand what you are implying regarding the timing "making sense". could you explain?

And thanks for moving the state of the art forward and benefiting us in the process...

I know nothing about inside of ESS dac. But from the timing, You can see with the inverted MCLK, the changing on I2S signal has more delay from the raising edge of MCLK than the normal one. I guess this may give ESS9018 a bit more "clean time" before issue a DS pulse. But I might be wrong .

Ian

 

[qusp]

yeah ha look I dunno, I know I asked for it ages ago by email or one of the threads (in May'ish), probably lost in the noise, but I was only parroting it from the datasheet and the Japanese crew so honestly its not really something I should get credit for either. Acko is playing with it also afaik and I have that option on titan, which was also initially designed for an ESS

 

[hochopeper]

I know nothing about inside of ESS dac. But from the timing, You can see with the inverted MCLK, the changing on I2S signal has more delay from the raising edge of MCLK than the normal one. I guess this may give ESS9018 a bit more "clean time" before issue a DS pulse. But I might be wrong .

Ian

Now that is an interesting concept Ian. Is the transition from high->low 'softer' also?

 

[iancanada]

yeah ha look I dunno, I know I asked for it ages ago by email or one of the threads (in May'ish), probably lost in the noise, but I was only parroting it from the datasheet and the Japanese crew so honestly its not really something I should get credit for either. Acko is playing with it also afaik and I have that option on titan, which was also initially designed for an ESS

Do you have link to those Japanese crew ?

Ian

 

[qusp]

Bunpei san (who always seems to be ahead of most in his ESS experiments), ElectrArt and those guys (mostly in Japanese language forums), Acko has it on his TurboClock etc. sorry just snippets I picked up along the way. I also chatted with the designers of titan about it because its a feature in Titan, i'll see if I can dig up the info.

I havent done any experimentation, not sure I trust my ears to pick up the difference, but it should technically be better for the reason you suggest, that the switching is done more in deadtime in relation to the other signals

 

[iancanada]

Bunpei san (who always seems to be ahead of most in his ESS experiments), ElectrArt and those guys (mostly in Japanese language forums), Acko has it on his TurboClock etc. sorry just snippets I picked up along the way. I also chatted with the designers of titan about it because its a feature in Titan, i'll see if I can dig up the info.

I havent done any experimentation, not sure I trust my ears to pick up the difference, but it should technically be better for the reason you suggest, that the switching is done more in deadtime in relation to the other signals

Thanks qusp,

Ian

 

[Popolvár]

FIFO stream status over Si570 board

... No any problem display the FIFO status and frequencies, as well as take over the frequency switching control within the window time.

Hi Ian,

So as I get it, it will be possible to query the status of the FIFO stream (frequency, errors, ...) over the Si570 board serial protocol you mentioned few days ago. It would be handy for some status display. Is this feature/"compatibility" valid also for the actual GBIII FIFO and SPDIF boards?

BTW I think that the chain of modules you provide is probably one the best ways to isolate the audio chain from the noisy PC environment (via optical SPDIF). None from the USB / I2S convertors can provide such isolation as I know.

Daniel

 

[hochopeper]

Hi Ian,

So as I get it, it will be possible to query the status of the FIFO stream (frequency, errors, ...) over the Si570 board serial protocol you mentioned few days ago. It would be handy for some status display. Is this feature/"compatibility" valid also for the actual GBIII FIFO and SPDIF boards?

As I understand it, the short answer is, yes the current functionality is compatible with the current FIFO firmware.

The difference is that the controller/display won't query the Si570, it will just be sent a message when an event occurs. This minimises serial communications and noise associated with it. The list of events that will be advertised via this channel is in Ian's serial protocol definition.

 

[Popolvár]

hochopeper,

Thanks for clarification, no need for query commands for that, events are fine. I am amazed in what detail is this designed. I am thinking about some simple microcontroler that will turn on LCD/VFD and will display the status in case of FIFO status change for some time (error, new stream with new frequency, ...) and then it will put itself into a sleep mode.

 

[hochopeper]

hochopeper,

Thanks for clarification, no need for query commands for that, events are fine. I am amazed in what detail is this designed. I am thinking about some simple microcontroler that will turn on LCD/VFD and will display the status in case of FIFO status change for some time (error, new stream with new frequency, ...) and then it will put itself into a sleep mode.

That is indeed the sort of thing that is possible. Though I am thinking web interface and OLED screen for myself. Also hoping to build the control/display unit into the playback device.

 

[iancanada]

hochopeper,

Thanks for clarification, no need for query commands for that, events are fine. I am amazed in what detail is this designed. I am thinking about some simple microcontroler that will turn on LCD/VFD and will display the status in case of FIFO status change for some time (error, new stream with new frequency, ...) and then it will put itself into a sleep mode.

It's possible. But an isolated display section is prefered. All display modules including LCD,TFT and OLED are noisy because of the scan. The MCU on clock board just works for very short of time during Fs switching. It will go into deep sleep for the rest time with only 15uA consumption.

Ian

 

[Bunpei]

Do you have link to those Japanese crew

Hi, Ian and qusp! Did you guys call me?

As for MCLK timing, wktk_smile once posted in the "ESS Sabre Reference DAC (8-channel)" thread as shown below;

In the Sabre dac app note, ESS recommends inverted MCLK when that's synchronous, although they only says
"The inverted MCLK ensures that the Sabre noise as low as possible." and there's no further explanations.

Anyone tried these?

As far as I tried myself, (I stolen MCLK from transport via LVDS and made inverted at the LVDS receiver input.)
I felt it's slightly better in SQ, but I can't say surely it's better because I haven't done strict A/B comparison yet.

Besides, I have no skill and equipments to measure noise performance correctly.

I 'm just curious what other people found or felt in synchronous + inverted MCLK.

Bunpei followed his post with this;

Hi, wktk_smile,

I'm not sure that this information has something to do with your interest.
The following Japanese web page by a DAC designer reported a possible noise. You may understand the contents written in Japanese language.

DAC

In the blog page by Mr. Kakuta of AIT Lab, a garage audio dac vendor in Japan, reported a result of his tuning efforts of the timing of synchronous MCLK for ES9018 showing spectra he obtained.

A.[Top] No tuning < 8.8kHz(?) single sine wave input (It is the worst case spectrum)>

B.[Middle] No tuning < 6kHz = 192kHz/32kHz single sine wave input >

C.[Bottom] Tuned. No spurious peaks.

An externally hosted image should be here but it was not working when we last tested it.

He said nothing about his measurement devices nor sampling frequencies.
I have no idea on what his spectra mean. However, wktk_smile's post reminded me of Kakuta's report.

Is this information helpful enough?

Bunpei

--------------------------------------
Winter, spring, summer or fall
All you have to do is call
And I'll be there
You've got a friend
--------------------------------------

 

[qusp]

yep thats the stuff thanks Angel Bunpei , the information all a bit vague but definitely worth experimentation, I guess they dont mention it in the datasheet for nothing. I tried some time ago with titan and results were inconclusive, in that I have no means of measuring the result