i2s sync error and resolution

[Lttlwing16]

I'm using a Rpi 3B+ with Allo Digione running MoOde.

My issue is I am having i2s sync errors in the /var/log/kern.log and my 24/96 files will not playback without stutter on first reboot.

However, if I play a 16/44.1 file the 24/96 files playback fine.

I've searched for answers on the internet and can't find an explanation of why this resolves the stuttering, despite the i2s sync error continuing in the /kern.log.

Allo has acknowledged the Digione needs repair, but wants me to pay for round trip shipping to and from India to repair. This would cost almost the cost of a new Digione.

To my ears, there aren't noticeable artifacts after things get ironed out with the 16/44.1 file, but wanted to make sure the clock errors aren't compromising the output stream of the 24/96 files.

Thanks,

David

 

[tomchr]

Does Allo say anything about the nature of the repair?

Tom

 

[Lttlwing16]

Does Allo say anything about the nature of the repair?

Tom

Hey Tom,

Thanks for taking the time to reply. Here is my back and forth with the Allo Rep on audiophilestyle.com:

Me:
What is the likelihood the Raspberry Pi is faulty and not the Digione? Can i2s sync error and stuttering occur due to the Raspberry Pi and not the Digione?

Allo:
We suspect sometime the clock is missing due to impedance difference on clock path, so we need to fine tune the path resistor on clock path. There is no hardware failure on the board. May not be issue with RPI.

Me:
Thanks for the reply, I assume this would be done with software, or does the resistor get replaced on the Digione?

Allo:
Not with software , need to do it on onboard.

Me:
And why would this correct itself after playing a single 16/44.1 file?

Allo:
Not always ,sometime the clock is missing due to impedance difference, so it is happening.

Each track playing time transmit that rate clock, its not syncs some times.

After playing 44.1k rate and play 96k time its syncs correctly.

END

So to me, an impedance issue in the path resistor..

 

[tomchr]

Sounds like what we at National Semiconductor would call a "design oversight". Basically they forgot a termination resistor or it isn't the right value. It also sounds like something you could fix yourself if they'd let you know which resistor needs replacement and to which value. That said, if you don't have the right tools mucking with that is likely to result in failure.
If you do have the tools to work with itty-bitty SMD parts, you could ask Allo for the appropriate resistor value and offer to change it yourself. You'd obviously waive the warranty and such.

It's not completely impossible for the sync to "fix itself" on a sample rate change. The clock that's used by the DAC is usually derived or cleaned up with a clock/data recovery circuit or a PLL. It is possible that the PLL is having trouble acquiring lock on the incoming clock due to the improper termination. Then the PLL gets a whack over the head when the sample rate changes and it locks to the incoming clock. I'm definitely hand-waving here, but based on Allo's explanation that's my best guess as to what might be going on.

Tom

 

[Lttlwing16]

Sounds like what we at National Semiconductor would call a "design oversight". Basically they forgot a termination resistor or it isn't the right value. It also sounds like something you could fix yourself if they'd let you know which resistor needs replacement and to which value. That said, if you don't have the right tools mucking with that is likely to result in failure.
If you do have the tools to work with itty-bitty SMD parts, you could ask Allo for the appropriate resistor value and offer to change it yourself. You'd obviously waive the warranty and such.

It's not completely impossible for the sync to "fix itself" on a sample rate change. The clock that's used by the DAC is usually derived or cleaned up with a clock/data recovery circuit or a PLL. It is possible that the PLL is having trouble acquiring lock on the incoming clock due to the improper termination. Then the PLL gets a whack over the head when the sample rate changes and it locks to the incoming clock. I'm definitely hand-waving here, but based on Allo's explanation that's my best guess as to what might be going on.

Tom

Really insightful feedback, thank you.

I can solder some large bits, I wouldn't dare with tiny transistors.

I also believe it is a design oversight in my generation of Allo Digione's, as I've seen threads posted around the same time mine was purchased (3/2020) with the exact same issue. The rub is I was only playing 16//44.1 files at that time and didn't start messing around with higher bit depth and sample rate until after the 1 year warranty was expired.

Another interesting bit is the "I2S sync error" continues in the kernel log even after the clock seems to have sync'd and the playback from all file types is without issue. This is what gave me concern that there was something else going on with the board, but it could also be that error is harmless.

Either way, that'll be the end of Allo for me, as I have a new Audiophonics DIGIPI+I2S HAT which was just delivered today, which I'll be replacing the Digione with. Perhaps I could sell it, warts and all.

Thanks again!

David

 

[Lttlwing16]

Hey just wanted to follow up and say I switched the HAT to an Audiophonics DIGIPI+I2S and I am still getting I2S sync errors in the kernel log of MoOde. Tim Curtis of MoOde state's he doesn't have the error with any of his audio devices. However, the internet has 1-2 pages of Google full of folks who have the same error with the bcm2835 Rpi and various HAT's.

I guess I need to switch out the 3B+ and confirm there isn't something wrong with the raspberry pi...

 

[Keened]

Hey just wanted to follow up and say I switched the HAT to an Audiophonics DIGIPI+I2S and I am still getting I2S sync errors in the kernel log of MoOde. Tim Curtis of MoOde state's he doesn't have the error with any of his audio devices. However, the internet has 1-2 pages of Google full of folks who have the same error with the bcm2835 Rpi and various HAT's.

I guess I need to switch out the 3B+ and confirm there isn't something wrong with the raspberry pi...

There are enough weird little audio gremlins with the 3B+ that I've seen popup on threads (that may or may not be the 3B's fault) that I'd steer clear of anything sub Pi4 as a rule of thumb.

 

[Lttlwing16]

There are enough weird little audio gremlins with the 3B+ that I've seen popup on threads (that may or may not be the 3B's fault) that I'd steer clear of anything sub Pi4 as a rule of thumb.

I'd like to, but the Pi4 is hard to find these days!