Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 KHz

[TNT]

So were is "I"?

//

 

[soekris]

So were is "I"?

//

where I have always been, in Denmark. Just as it says on soekris.dk....

 

[TNT]

Well, it might be clear for you but rest assured it is not easy to follow for us externals... sites here and there - not valid stock information....

Get a .com domain and stay with it no matter. That will make it easier for your customers.

BTW: Why do you need to update the clock 1000 times a second for a 1021 run from i2s? That must be something wrong with the algorithms and/or data buffer size? I have seen the traces... surely it will make a trace in the midrange clarity....

//

 

[TNT]

By update I mean clock frequency adjustments. When you described your digital PLL solution it sounded like you would need at the most a clock change once a minute. Apparently it is 1khz. Is this how it should work?

//

 

[soekris]

Well, it might be clear for you but rest assured it is not easy to follow for us externals... sites here and there - not valid stock information....

Get a .com domain and stay with it no matter. That will make it easier for your customers.

I do have soekris.com, used to be used for the US computer products company, which is now closed.

At some point the .com will also point to the .dk site. And at some point the website will be updated to be more sales oriented....

/

BTW: Why do you need to update the clock 1000 times a second for a 1021 run from i2s? That must be something wrong with the algorithms and/or data buffer size? I have seen the traces... surely it will make a trace in the midrange clarity....

//

The dam1021 uC have a timer running at 400 hz, needed for early power off warning for the muting circuit and for other timing functions.... Don't have anything running 1000 times per second.

You're not thinking about the dam19x1 ? The timer is running faster there for switch debouncing, I2S sample rate detection and display updating....

The uC code is old by now, could update it to only run as needed, but it's not that simple, and I believe there is enough distance between the digital and analog parts....

 

[TNT]

OK!

It would be very interesting to hear a version where after you have acquired lock / sample rate, would leave the clock "alone". Just let it oscillate by itself without interference. Check for buffer over/under-run and adjust. Until something major is changed where it seem to be in needed for a higher rate...

Just saying...

Maybe this is why people still report sound change using different interfaces... I have so far said that that is nonsense but now I'm not so sure anymore.. I misunderstood you technical description of the function at the time - or you did not reveal the whole story.

//

 

[TNT]

Yes - maybe it was for 19x1. 400Hz is no better.

I mean - whats the purpose of a low jitter clock??

//

 

[soekris]

OK!

It would be very interesting to hear a version where after you have acquired lock / sample rate, would leave the clock "alone". Just let it oscillate by itself without interference. Check for buffer over/under-run and adjust. Until something major is changed where it seem to be in needed for a higher rate...

Just saying...

Maybe this is why people still report sound change using different interfaces... I have so far said that that is nonsense but now I'm not so sure anymore.. I misunderstood you technical description of the function at the time - or you did not reveal the whole story.

//

I'm more for multiple small clock adjustments instead of fewer larger ones, have a fear that larger ones would be noticeable at some time....

 

[TNT]

But I do realise now why you didn't pick up on my suggestion for a printout every time the clock was adjusted. But if you implement 2 different "gears", a counter to be added by 1 each time a "real" clock adjust was made in "play track" gear. One could print that register by command to see how many clock adjustments where made. With this, the user can optimise the quality of the connection to the DAC and get the best sound.

Everybody wins!

//

re: clock adjustment size.. how about the buffer. At least s/pdif has a specified tolerance which could be used to calculate the max needed buffer. But clocks are very good these days.

It must be possible to define an adaptive/intelligent algorithm that makes fewer adjustments / minute if clock is stable and vv.

//

 

[soekris]

Yes - maybe it was for 19x1. 400Hz is no better.

I mean - whats the purpose of a low jitter clock??

//

What do the low jitter master clock have to do with the uC internal clock ???

 

[TNT]

Well, I'm talking about "SI-514" adjustments!

Or give the user a choice to gamble with fewer but larger changes via a parameter. For some it will work, for others - not.

//

 

[TNT]

272864-272864 I≤C: Address/Data: Start
272895-272899 I≤C: Address/Data: Write
272867-272895 I≤C: Address/Data: Address write: 55
272899-272903 I≤C: Address/Data: ACK
272903-272934 I≤C: Address/Data: Data write: 05
272934-272938 I≤C: Address/Data: ACK
272938-272970 I≤C: Address/Data: Data write: B8
272970-272974 I≤C: Address/Data: ACK
272975-272975 I≤C: Address/Data: Stop
273020-273020 I≤C: Address/Data: Start
273051-273055 I≤C: Address/Data: Write
273023-273051 I≤C: Address/Data: Address write: 55
273055-273059 I≤C: Address/Data: ACK
273059-273090 I≤C: Address/Data: Data write: 06
273090-273094 I≤C: Address/Data: ACK
273094-273126 I≤C: Address/Data: Data write: 4E
273126-273130 I≤C: Address/Data: ACK
273131-273131 I≤C: Address/Data: Stop
273176-273176 I≤C: Address/Data: Start
273207-273211 I≤C: Address/Data: Write
273179-273207 I≤C: Address/Data: Address write: 55
273211-273215 I≤C: Address/Data: ACK
273215-273245 I≤C: Address/Data: Data write: 07
273246-273249 I≤C: Address/Data: ACK
273250-273282 I≤C: Address/Data: Data write: EB
273282-273286 I≤C: Address/Data: ACK
273287-273287 I≤C: Address/Data: Stop
273332-273332 I≤C: Address/Data: Start
273363-273367 I≤C: Address/Data: Write
273335-273363 I≤C: Address/Data: Address write: 55
273367-273371 I≤C: Address/Data: ACK
273371-273403 I≤C: Address/Data: Data write: 08
273402-273406 I≤C: Address/Data: ACK
273406-273438 I≤C: Address/Data: Data write: 78
273438-273442 I≤C: Address/Data: ACK
273443-273443 I≤C: Address/Data: Stop
273488-273488 I≤C: Address/Data: Start
273519-273523 I≤C: Address/Data: Write
273491-273519 I≤C: Address/Data: Address write: 55
273523-273527 I≤C: Address/Data: ACK
273527-273559 I≤C: Address/Data: Data write: 09
273559-273563 I≤C: Address/Data: ACK
273562-273594 I≤C: Address/Data: Data write: 08
273594-273598 I≤C: Address/Data: ACK
273599-273599 I≤C: Address/Data: Stop


372659-372659 I≤C: Address/Data: Start
372689-372693 I≤C: Address/Data: Write
372662-372689 I≤C: Address/Data: Address write: 55
372693-372697 I≤C: Address/Data: ACK
372697-372729 I≤C: Address/Data: Data write: 05
372729-372733 I≤C: Address/Data: ACK
372733-372764 I≤C: Address/Data: Data write: 92
372764-372768 I≤C: Address/Data: ACK
372769-372769 I≤C: Address/Data: Stop
372815-372815 I≤C: Address/Data: Start
372845-372849 I≤C: Address/Data: Write
372818-372845 I≤C: Address/Data: Address write: 55
372849-372853 I≤C: Address/Data: ACK
372853-372885 I≤C: Address/Data: Data write: 06
372885-372889 I≤C: Address/Data: ACK
372889-372919 I≤C: Address/Data: Data write: 4B
372920-372923 I≤C: Address/Data: ACK
372925-372925 I≤C: Address/Data: Stop
372971-372971 I≤C: Address/Data: Start
373001-373005 I≤C: Address/Data: Write
372974-373001 I≤C: Address/Data: Address write: 55
373005-373009 I≤C: Address/Data: ACK
373009-373041 I≤C: Address/Data: Data write: 07
373041-373045 I≤C: Address/Data: ACK
373045-373077 I≤C: Address/Data: Data write: EB
373076-373080 I≤C: Address/Data: ACK
373082-373082 I≤C: Address/Data: Stop
373127-373127 I≤C: Address/Data: Start
373157-373161 I≤C: Address/Data: Write
373130-373157 I≤C: Address/Data: Address write: 55
373161-373165 I≤C: Address/Data: ACK
373165-373197 I≤C: Address/Data: Data write: 08
373197-373201 I≤C: Address/Data: ACK
373201-373233 I≤C: Address/Data: Data write: 78
373232-373236 I≤C: Address/Data: ACK
373238-373238 I≤C: Address/Data: Stop
373283-373283 I≤C: Address/Data: Start
373313-373317 I≤C: Address/Data: Write
373286-373313 I≤C: Address/Data: Address write: 55
373317-373321 I≤C: Address/Data: ACK
373321-373353 I≤C: Address/Data: Data write: 09
373353-373357 I≤C: Address/Data: ACK
373357-373389 I≤C: Address/Data: Data write: 08
373388-373392 I≤C: Address/Data: ACK
373394-373394 I≤C: Address/Data: Stop

etc...

//

 

[soekris]

But I do realise now why you didn't pick up on my suggestion for a printout every time the clock was adjusted. But if you implement 2 different "gears", a counter to be added by 1 each time a "real" clock adjust was made in "play track" gear. One could print that register by command to see how many clock adjustments where made. With this, the user can optimise the quality of the connection to the DAC and get the best sound.

Everybody wins!

I have debug code that do just that, so I know how fast it happens, and I'm happy with what I see.... But I don't want to waster uC time and screen space to show it normally, plus more question from you

//

re: clock adjustment size.. how about the buffer. At least s/pdif has a specified tolerance which could be used to calculate the max needed buffer. But clocks are very good these days.

buffer size have been defined based on what delay you can tolerate, especially when used together with video.... And clocks are not good nowadays, remember RPi ? Not many DACS can tolerate the clock from a RPi.....

It must be possible to define an adaptive/intelligent algorithm that makes fewer adjustments / minute if clock is stable and vv.

//

Already do that.... I'm planning to increase resolution in clock calculations at some point, which will improve on how often adjustment is needed....

 

[soekris]

272864-272864 I≤C: Address/Data: Start
272895-272899 I≤C: Address/Data: Write
272867-272895 I≤C: Address/Data: Address write: 55
272899-272903 I≤C: Address/Data: ACK
272903-272934 I≤C: Address/Data: Data write: 05
272934-272938 I≤C: Address/Data: ACK
272938-272970 I≤C: Address/Data: Data write: B8
272970-272974 I≤C: Address/Data: ACK
272975-272975 I≤C: Address/Data: Stop
273020-273020 I≤C: Address/Data: Start
273051-273055 I≤C: Address/Data: Write
273023-273051 I≤C: Address/Data: Address write: 55
273055-273059 I≤C: Address/Data: ACK
273059-273090 I≤C: Address/Data: Data write: 06
273090-273094 I≤C: Address/Data: ACK
273094-273126 I≤C: Address/Data: Data write: 4E
273126-273130 I≤C: Address/Data: ACK
273131-273131 I≤C: Address/Data: Stop
273176-273176 I≤C: Address/Data: Start
273207-273211 I≤C: Address/Data: Write
273179-273207 I≤C: Address/Data: Address write: 55
273211-273215 I≤C: Address/Data: ACK
273215-273245 I≤C: Address/Data: Data write: 07
273246-273249 I≤C: Address/Data: ACK
273250-273282 I≤C: Address/Data: Data write: EB
273282-273286 I≤C: Address/Data: ACK
273287-273287 I≤C: Address/Data: Stop
273332-273332 I≤C: Address/Data: Start
273363-273367 I≤C: Address/Data: Write
273335-273363 I≤C: Address/Data: Address write: 55
273367-273371 I≤C: Address/Data: ACK
273371-273403 I≤C: Address/Data: Data write: 08
273402-273406 I≤C: Address/Data: ACK
273406-273438 I≤C: Address/Data: Data write: 78
273438-273442 I≤C: Address/Data: ACK
273443-273443 I≤C: Address/Data: Stop
273488-273488 I≤C: Address/Data: Start
273519-273523 I≤C: Address/Data: Write
273491-273519 I≤C: Address/Data: Address write: 55
273523-273527 I≤C: Address/Data: ACK
273527-273559 I≤C: Address/Data: Data write: 09
273559-273563 I≤C: Address/Data: ACK
273562-273594 I≤C: Address/Data: Data write: 08
273594-273598 I≤C: Address/Data: ACK
273599-273599 I≤C: Address/Data: Stop


372659-372659 I≤C: Address/Data: Start
372689-372693 I≤C: Address/Data: Write
372662-372689 I≤C: Address/Data: Address write: 55
372693-372697 I≤C: Address/Data: ACK
372697-372729 I≤C: Address/Data: Data write: 05
372729-372733 I≤C: Address/Data: ACK
372733-372764 I≤C: Address/Data: Data write: 92
372764-372768 I≤C: Address/Data: ACK
372769-372769 I≤C: Address/Data: Stop
372815-372815 I≤C: Address/Data: Start
372845-372849 I≤C: Address/Data: Write
372818-372845 I≤C: Address/Data: Address write: 55
372849-372853 I≤C: Address/Data: ACK
372853-372885 I≤C: Address/Data: Data write: 06
372885-372889 I≤C: Address/Data: ACK
372889-372919 I≤C: Address/Data: Data write: 4B
372920-372923 I≤C: Address/Data: ACK
372925-372925 I≤C: Address/Data: Stop
372971-372971 I≤C: Address/Data: Start
373001-373005 I≤C: Address/Data: Write
372974-373001 I≤C: Address/Data: Address write: 55
373005-373009 I≤C: Address/Data: ACK
373009-373041 I≤C: Address/Data: Data write: 07
373041-373045 I≤C: Address/Data: ACK
373045-373077 I≤C: Address/Data: Data write: EB
373076-373080 I≤C: Address/Data: ACK
373082-373082 I≤C: Address/Data: Stop
373127-373127 I≤C: Address/Data: Start
373157-373161 I≤C: Address/Data: Write
373130-373157 I≤C: Address/Data: Address write: 55
373161-373165 I≤C: Address/Data: ACK
373165-373197 I≤C: Address/Data: Data write: 08
373197-373201 I≤C: Address/Data: ACK
373201-373233 I≤C: Address/Data: Data write: 78
373232-373236 I≤C: Address/Data: ACK
373238-373238 I≤C: Address/Data: Stop
373283-373283 I≤C: Address/Data: Start
373313-373317 I≤C: Address/Data: Write
373286-373313 I≤C: Address/Data: Address write: 55
373317-373321 I≤C: Address/Data: ACK
373321-373353 I≤C: Address/Data: Data write: 09
373353-373357 I≤C: Address/Data: ACK
373357-373389 I≤C: Address/Data: Data write: 08
373388-373392 I≤C: Address/Data: ACK
373394-373394 I≤C: Address/Data: Stop

etc...

//

I have no clue about the time scale, but remember that adjustments go down over time, just as it should when using a regular butterworth filter in the digital PLL....

 

[TNT]

I have not seen or done any measurements of these clocks under/after a freq change. But I suspect, that is has a settle time where it rings and behaves... now, if one change this clock 100 / 1000 time per second, what you get is a clock mess compared to just let i oscillate.

I'm sure it "works" well, but did we get the full potential out of the DAC in this way?

Let user decide to prioritise delay or SQ?

//

 

[TNT]

I have no clue about the time scale, but remember that adjustments go down over time, just as it should when using a regular butterworth filter in the digital PLL....

OK! What is the lowest you have seen and with what interface type?

//

PS. It's Your I2S bus so you should know.

PPS: uS?

PPS. I mean I suppose you know the time between "Writes" on the bus and should be able to undertand the timestamps I suppose...

//

 

[soekris]

OK! What is the lowest you have seen and with what interface type?

//

PS. It's Your I2S bus so you should know.

PPS: uS?

PPS. I mean I suppose you know the time between "Writes" on the bus and should be able to undertand the timestamps I suppose...

//

Remember, I designed this something like five years ago, so don't expect me to remember details....

Anyway, I have more important things to do (like adding 4K taps support to the dam1121) than adding firmware options that a few people think they need, and I see no need for....

 

[soekris]

I have not seen or done any measurements of these clocks under/after a freq change. But I suspect, that is has a settle time where it rings and behaves... now, if one change this clock 100 / 1000 time per second, what you get is a clock mess compared to just let i oscillate.

I'm sure it "works" well, but did we get the full potential out of the DAC in this way?

Let user decide to prioritise delay or SQ?

//

On your data, I see two updates with 100 mS between them, which is the minimum time between updates.... where are the 100-1000 times per second ???

 

[TNT]

4k for 1121 would of course be very welcome. Looking FW to that. A general reduction of the SQ impact from clock adjustments would benefit the whole line I suppose and maybe, just maybe would finally lift your exquisite products into the real "fine-room". As of now, its kind of appreciated in the DIY community but it has not really take off into the big game fishing department - has it? Maybe this is what is hindering it?

For the 100/1000per second aspect I actually looked at the frequency of all interaction towards the clock - even writes (a 1ms process) probably effect this delicate instrument so... again - my choice would be to find a way to leave it alone - for as long as absolutely possible.

Here is series of a few other consecutive adjustment starts:

7259037-7259037 I≤C: Address/Data: Start
7857842-7857842 I≤C: Address/Data: Start
7957650-7957650 I≤C: Address/Data: Start (1ms!!!)
9654303-9654303 I≤C: Address/Data: Start

So it really varies it seems.

I wish you would have interest and time to try e.g. a bigger buffer + an user option to accept larger delays for us who don't watch TV but try to build a SOTA audio system. But that is followed by a big "pretty please"

//

PS. I plotted the time stamps towards linear event occasions. In an ideal world there would be long vertical lines indicating that between 2 events, a long time had passed. Longer horizontal lines indicates more intense adjustments.

 

[TNT]

Or a mode where the DAM adopts I2S master and sets the clock once and for all - to never touch it again until next power on. (bar Fs changes)

//