Build Thread for TPA BIII + Ian Async I2S FIFO + OPC NTD1 + Salas SSLV

[hochopeper]

What qusp said.

This is just rough psuedocode because I haven't written anything for arduino in a while so syntax is a bit hazy but you'll see where I'm going.


This will have to change if you end up going to Si570 for masterclock because MCKLx will be a set of frequencies where with the dual clock board you know the 2 freq for master clock and you know that the FIFO will be determining that based on the input sample freq.


Basically what I think what you'll have to do is in effect something like this:

int MCKL1 = 45158400;
int MCKL2 = 49152000;
int register;

[whatever code already returns register value in hifiduino]

[some code to determine if BIII is returning a rate that is a 44.1kHz multiple or if it is a multiple of 48kHz]

if (BIII register a multiple of 44.1):
     fs = register/MCKL1;
if (BIII register a multiple of 48):
    fs = register/MCKL2;

As you have noted, this change is necessary regardless of what master clock source you use, the hifiduino is written for async so there will only ever be one constant value used for master clock.

 

[bigpandahk]

Thanks qusp and hochopeper

I can still read the register of BIII and is trying to understand how HiFiDuino calculate the magic number and divid the figure in the register by the magic number to get the frequency

hochopeper, very good point, it will be very difficult to calculate the frequency if I use the i570. May be Ian has to add output header for different frequencies

 

[hochopeper]

Actually, the group of frequencies for ES901x DACs from the Si570 is still dual master clock, but at the faster rate. The multiplier changes to keep MCLK as detailed in this post from Ian, so you could conceivably use whatever code for the dual master clock board again for the Si570.

// Group4:Si570 frequency and *Fs combination for high mclk
{F903168, 2048*FS}, //2 44.1 KHz
{F983040, 2048*FS}, //3 48 KHz
{F903168, 1024*FS}, //4 88.2 KHz
{F983040, 1024*FS}, //5 96 KHz
{F903168, 512*FS }, //6 176.4KHz
{F983040, 512*FS }, //7 192 KHz
{F903168, 256*FS }, //8 352.8KHz
{F983040, 256*FS } //9 384 KHz

It should be possible to determine which of the above conditions is being used and apply the correct inputs to the formula to calculate and display FS.

 

[bigpandahk]

Actually, the group of frequencies for ES901x DACs from the Si570 is still dual master clock, but at the faster rate. The multiplier changes to keep MCLK as detailed in this post from Ian, so you could conceivably use whatever code for the dual master clock board again for the Si570.



It should be possible to determine which of the above conditions is being used and apply the correct inputs to the formula to calculate and display FS.

Thanks, but it will take me sometime to understand HifiDuino's method on frequency calculation

 

[hochopeper]

I just downloaded the hifiduino code and had a look, I think glt has used a constant depending on what asynch masterclock is on the BIII board ( 80 or 100 MHz).

You will need to set this as a variable and edit the I2S calculation inside the block of code

unsigned long sampleRate() {
//leave the code used to read registers and create 32bit number



//then change the calculation to first calculate if the DPLLnum is closer to a multiple of 44.1 or 48kHz.

//that will determine which MCLK freq the FIFO is using

//then divide by the correct number to give your fs

}

That's basically the changes I think will need to be made to that function. Since I don't have a ES901x DAC or hifiduino I'm not prepared to have a stab at the code because I can't easily test it.

 

[qusp]

ahh yes the DPLL NUM pin/registers, but I suppose thats where the BIII onboard MCU is getting this info from and rebroadcasting it for the arduino to pick up via i2c

 

[bigpandahk]

I read the DPLLNum register during Async and Sync mode, the figure is quite stable at Async but it drifting a lot during sync mode. It is not possible to calculate it

With the default constant in glt's code, it shows 192000 at Async but showing 0, 1472, 39xxxx, 24xxxxxx, 25xxxxxx in Sync mode

 

[hochopeper]

I believe that it should be possible to calculate it, I need to read the datasheet to give you better advice though. What I am thinking at the moment is to truncate the result from that register and then compare to a set of ranges and depending on the range it falls in it should be able to determine which fs is being used.


Also, what are the frequencies two clocks that you are using in the dual clock board at the moment?

I will dig up my copy of the datasheet tomorrow and if I have any ideas I'll let you know.

 

[glt]

Thanks, but it will take me sometime to understand HifiDuino's method on frequency calculation

The "magic" number is just an integer value that will give the closest match to a floating point calculation. When I started doing this, I figure I would use integer operation rather than floating point because floating point operation is "slow" in the arduino.

But the "magic" number should still work with the new frequency by replacing 80000000 or 100000000 with the new master frequency from the FIFO. However, I can't think of any way to detect that the master frequency has changed unless indicated by the FIFO

But, one way you can do it locally is to determine the error in the sample rate calculation: if the error is "too large" compared to what it is expected, then you switch to the other frequency.

There is one more things: According to Dustin in this article: 6moons audio reviews: Wyred4Sound DAC2

" You can use the ASRC if you like - or not by simply clocking the XIN pin synchronously (at an integer multiple) to the BCLK. Then the ASRC drops itself out, reverting in this case to a more conventional method as the other DACs I'm aware of do."

I don't know what it means by "drops itself out", but if DAC determines that the signal is synchronous, it may choose to disable the ASRC and therefore the DPLL may be just "freewheeling" Check comment #4 in this post: Poor Man’s Jitter Measurement H i F i D U I N O

Again I don't know exactly what is "freewheeling", but it could mean the DPLL is just "going all over the place". If this is the case, then you cannot calculate the sample rate.

Thanks for sharing all the work guys

 

[bigpandahk]

I believe that it should be possible to calculate it, I need to read the datasheet to give you better advice though. What I am thinking at the moment is to truncate the result from that register and then compare to a set of ranges and depending on the range it falls in it should be able to determine which fs is being used.


Also, what are the frequencies two clocks that you are using in the dual clock board at the moment?

I will dig up my copy of the datasheet tomorrow and if I have any ideas I'll let you know.

Thanks again for your help, I am using the same frequencies as Ian, 45.1584 & 49.1520.

 

[glt]

I believe that it should be possible to calculate it, I need to read the datasheet to give you better advice though. What I am thinking at the moment is to truncate the result from that register and then compare to a set of ranges and depending on the range it falls in it should be able to determine which fs is being used.


Also, what are the frequencies two clocks that you are using in the dual clock board at the moment?

I will dig up my copy of the datasheet tomorrow and if I have any ideas I'll let you know.

I repeated what you said . That is the way to do it.

 

[bigpandahk]

The "magic" number is just an integer value that will give the closest match to a floating point calculation. When I started doing this, I figure I would use integer operation rather than floating point because floating point operation is "slow" in the arduino.

But the "magic" number should still work with the new frequency by replacing 80000000 or 100000000 with the new master frequency from the FIFO. However, I can't think of any way to detect that the master frequency has changed unless indicated by the FIFO

But, one way you can do it locally is to determine the error in the sample rate calculation: if the error is "too large" compared to what it is expected, then you switch to the other frequency.

There is one more things: According to Dustin in this article: 6moons audio reviews: Wyred4Sound DAC2

" You can use the ASRC if you like - or not by simply clocking the XIN pin synchronously (at an integer multiple) to the BCLK. Then the ASRC drops itself out, reverting in this case to a more conventional method as the other DACs I'm aware of do."

I don't know what it means by "drops itself out", but if DAC determines that the signal is synchronous, it may choose to disable the ASRC and therefore the DPLL may be just "freewheeling" Check comment #4 in this post: Poor Man’s Jitter Measurement H i F i D U I N O

Again I don't know exactly what is "freewheeling", but it could mean the DPLL is just "going all over the place". If this is the case, then you cannot calculate the sample rate.

Thanks for sharing all the work guys

Thanks for your advice, If the value in the DPLLNum register is constant or only shift a little, it will not be difficult to find the magic number. I use the code below to print out the value in each register:

unsigned long sampleRate() {
myGLCD.setFont(SmallFont);
myGLCD.setColor(255, 255, 255);
DPLLNum=0;
// Reading the 4 registers of DPLL one byte at a time and stuffing into a single 32-bit number
DPLLNum|=readDPLL(31);
myGLCD.print("1",250,70);
myGLCD.printNumI(readDPLL(31),280,70);
DPLLNum<<=8;
DPLLNum|=readDPLL(30);
myGLCD.print("2",250,90);
myGLCD.printNumI(readDPLL(30),280,90);
DPLLNum<<=8;
DPLLNum|=readDPLL(29);
myGLCD.print("3",250,110);
myGLCD.printNumI(readDPLL(29),280,110);
DPLLNum<<=8;
DPLLNum|=readDPLL(28);
myGLCD.print("4",250,130);
myGLCD.printNumI(readDPLL(28),280,130);
// The following calculation supports 80 MHz oscillator

if (SPDIFValid){
DPLLNum*=20; // Calculate SR for SPDIF -100MHz part
DPLLNum/=859; // Calculate SR for SDPIF -100MHz part
myGLCD.print("SPDIF",280,200);
}
else { // Different calculation for SPDIF and I2S
DPLLNum*=4; // Calculate SR for I2S -100MHz part
DPLLNum/=10995; // Calculate SR for I2S -100MHz part
myGLCD.print("I2S ",280,200);
}
if(bypassOSF) // When OSF is bypassed, the magnitude of DPLL is reduced by a factor of 64
DPLLNum*=64;

// myGLCD.printNumI(DPLLNum, 280,70);
return DPLLNum;

All 4 registers are not showing a constant number.
DPLL(31) : 63 or 64
DPLL(30) : 0 or 055 or 255
DPLL(29) : 055 or 255
DPLL(28) : vary.

 

[qusp]

I interpret 'freewheeling' as in freewheeling on a pushbike, like when you are going down a hill and you cant pedal fast enough to get any purchase, but you are still going where you want to go, so you just sit there and the bearing spins with the wheel without you having to do any work.

 

[qusp]

hmm, maybe BCLK is going to be your best bet, using BCLK combined with the signals on J13 on fifo. pin 1 on J13 is the SILENCE indicator used to mute the dac during change of clocks, you could use this to signal a change and get arduino to look at BCK at that point, remembering the last value and comparing to it.

but then I should shut up at this point. coding is not on my list of skills

 

[Bunpei]

But Synchronize mode cause a new problem, Arduino can't display the correct clock frequency

It's a well-known issue among people those who apply a synchronous master clocking scheme.
http://www.diyaudio.com/forums/digital-line-level/117238-ess-sabre-reference-dac-8-channel-190.html#post2923487

My understandings are;
1. ES9018 does not know any absolute frequency of MCLK, BCLK.
2. DPLL number registers represent a ratio, BCLK/MCLK [in the case of I2S or DSD ] or fs/MCLK [S/PDIF] in the format of unsigned 32 bit integer.
3. The DPLL function is always on even when a synchronous MCLK is applied. However, almost no actual effective feedback adjustment appears in this case. This is described as "freewheeling" by Russ.

 

[bigpandahk]

Yeah, I am most interested in this bug . The way it is currently programmed (as dimdim said) is that every input has independent settings for each function, and they are saved in eeprom. When you switch to another input, the settings are recalled from the eeprom and programmed into the registers. Granted, not all of the them would change, but it was easiest to just rewrite all the values into the registers everytime you change inputs.

Could you please point me to the section of code that store settings for individual input?

 

[glt]

Could you please point me to the section of code that store settings for individual input?

Look for EEPROM.write() and EEPROM.read()

 

[bigpandahk]

Look for EEPROM.write() and EEPROM.read()

Thanks, I thought that there are default settings for different inputs. Instead, the code memory the parameters for each input and recall them when selected.

I have to take out my previous "Bug fixing"

 

[bigpandahk]

It's a well-known issue among people those who apply a synchronous master clocking scheme.
http://www.diyaudio.com/forums/digital-line-level/117238-ess-sabre-reference-dac-8-channel-190.html#post2923487

My understandings are;
1. ES9018 does not know any absolute frequency of MCLK, BCLK.
2. DPLL number registers represent a ratio, BCLK/MCLK [in the case of I2S or DSD ] or fs/MCLK [S/PDIF] in the format of unsigned 32 bit integer.
3. The DPLL function is always on even when a synchronous MCLK is applied. However, almost no actual effective feedback adjustment appears in this case. This is described as "freewheeling" by Russ.

Thanks for the information, I am afraid the solution will be Ian adding this feature into the clock board!

 

[bigpandahk]

After installed Ian's isolator board, the bass become much clear and powerful. I am waiting for the i8605 for the additional isolation on the I2C bus.
Today, receive the battery management board and will assemble it ASAP.
Unfortunately, my DAC has a new problem, actually it should be old issue but happen more frequent. When I used the Legato for couple of days, I found its temperature is abnormally high. Some resistors reach 75 deg. C after 20-30 minutes operation. I have raised this query in the TPA support forum but was told it is normal.
Now, I believe the high temperature already damage some component(s). Last month the Legato start to fail after couple hours, but now it can only survive for several minutes.
Both channels have no sound when fail, any suggestion to trace the problem? Please!!