I2S from RPI - Not conform with standard ? Looking for someone to confirm (or not)

[dddac]

Hi everyone,

I recently did some testing and had measured I2S signals coming from my different sources. Digital output from the audio precision (exact I2S protocol), my WaveIO and my RPI 3B Running Ropieee as Roon endpoint.

I will show signals in the next posts. My request is, if anyone with an oscilloscope could measure the Wordclock (or LR) and DATA output together so I have a confirmation that something is not 100% or that there is something in my setup not correct, which could be the case of course. Hence this request…. I just need a totally different setup somewhere for comparison of the signals

Thanks in advance !
Doede

 

[dddac]

This I how an I2S ideally would look like

When LR changes to next sample, there is one clock cycle nothing / delay and than comes a 16 or in this case 24 bit word, MSB first

 

[dddac]

If I measure the same signals from a RPI running Ropieee unser Roon I get this…

It looks like there is an extra delay of 1 clock cycle and also I count 15 bits somehow
But most strange, the padding of logical “ones” where you would expect zeroes… see image

Harry from Ropieee mentioned it is standard Linux functions so he could not understand either

I also tried (no picture) volumino as roon endpoint and had similar things, but not 100% the same…. But still ones where I expect zero and the extra delay

So anyone out there picking I2S from a RPI I would be very interested to see YOUR LR vs DATA signals …

 

[dddac]

Oh, I chose generic I2S outputs, not a specific brand DAC…

And the DAC works fine with this, that is not the point, I was just surprised I actually measured these unexpected signals

 

[Mark Tillotson]

Its common for the data pin state to persist upto the next half-cycle or LRCLK, if the RPi is working correctly (MSB not corrupt), then it must be clocking out the MSB of next half-cycle at the end of the previous one. If the LSB on one half-cycle leaked to the MSB of the next the result would be ugly to listen to!

I can imagine how this could come about, for instance the 16 bit data is sign-extended into a 32 bit word, and this is pushed out by DMA 17 BCLK cycles after the LRCLK transition.

 

[dddac]

Thanks Mark, so in fact the RPI is doing this?
I am puzzled why, as it is not according to I2S standards. But I am not a Linux or RPI expert.
Still, it would be nice if there are DIY's who will be willing to post a picture from there scope measurement.

 

[Mark Tillotson]

If it does this its conformant as the data only has to be valid on the relevant clock edges, and polluting the LSBs of the previous word is hardly an issue. Implementation can do all sorts of devious things if it wants, so long as the relevant 16 bits are correct on the output - having said that its worth checking they are (although I'm pretty certain if they weren't it would make horrible noise).

Nothing I said is Linux or RPi related, just a general observation on how the data might be being generated like this (you can assume DMA is involved in all sane cases).

 

[dddac]

Thanks Mark for further elaboration....