I2S Slave Library specification non-compliance report Topic is solved

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
SirShagsalot
Member
Posts: 10
Joined: Fri Aug 04, 2017 4:33 am

I2S Slave Library specification non-compliance report

Postby SirShagsalot » Fri Aug 04, 2017 9:08 am

Hi,

Following on from my previous post (which appears to have been harmonised) we identified a fundamental failure of the I2S_slave component to comply with I2S specification as issued by Philips in 1986 which remains the valid standard for I2S.

The I2S specification merely states that the Bitclock must be at least equal to the number of bits being transmitted. It may be greater, but in principle it is perfectly specification compliant to transmit 18 Bit data on I2S with a Bitclock that is 36 * WCK, For any I2S source it cannot be expected to have a reliable 1/64 ratio between WCK & BCK.

Many SOC's that deliver Audio via I2S will deliver it with a BCK rate matched to the source Bit-depth. As 18/20/22 Bit audio is not implemented in any commercial source of audio (files), though it may be present with historical ADC Chips (where we may also find 12/14 Bit) the I2S slave must at least support the following BCK/WCK ratios, if a support of "any BCK/WCK ratio coming in" is not easy enough to implement:

16 Bit Data -> BCK = 32 WCK
24 Bit Data -> BCK = 48 WCK
32 Bit Data -> BCK = 64 WCK

Bit depth may change from song to song played without getting any change indication form the SOC producing the stream.

Thus the BCK/WCK ratio may vary constantly. Hence the I2S slave component should operate frame based using WCK as start frame indicator with BCK allowed to take any value or at least 32/48/64 * WCK.

In order to deliver 32 Bit samples to the following routines the actual significant bits of the Sample must be suitably shifted so that the LSB's are automatically filled with zero's.

In order to decode (for example) DoP-DSD, HDCD, AC3, DTS or other encoding in an I2S data stream it is not acceptable to use ASRC to correct any sample rate mismatch.

Thus it would further be EXTREMELY desirable to have the I2S slave routine to output a PLL clock sync signal at 300Hz compatible with the use of the CS2100 PLL to match the XMOS system clock to the I2S source (as done by clockgen.xc for SPDIF & ADAT) either on it's own or by integrating with clockgen.

Greez SSAL
View Solution
User avatar
infiniteimprobability
XCore Expert
Posts: 886
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Wed Aug 09, 2017 7:50 am

Hi Greez,
This is an investing one. Both the lib_i2s library and the i2s embedded within the USB audio reference design assume 32 BCLKs per audio channel (and assume left justification with zero padding in the case of len<32). in fact lib_i2s docs state this specification:

The xCORE I2S library assumes 32 bits of data between *LRCLK* transitions.


The reason for this is that all CODECs/DSPs we have been requested to interfaced to support 32b. It also happens to be a native serdes size for the buffered mode of a 1b port. This means the xcore just reads/writes a 32b value and the buffered/clocked ports do the rest which gains a lot of performance.
This is actually the first time I can recall a request for len!=32 although I take your point it's supported by the spec and some older devices.

It should be possible to use the partout(port, len, val) partin(port, len) built-ins to support len <32. It would likely need to know the word length up-front though to achieve decent performance as the shift register in the port needs to know when the transfer register needs to be populated. The main job here though is verifying and characterising all of the different modes and settings (sample rate, channel counts, bit lengths, I2S modes) which would definitely need automating as it soon multiplies up to a lot of permutations..
User avatar
infiniteimprobability
XCore Expert
Posts: 886
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Wed Aug 09, 2017 7:52 am

Regarding:

Thus it would further be EXTREMELY desirable to have the I2S slave routine to output a PLL clock sync signal at 300Hz compatible with the use of the CS2100 PLL to match the XMOS system clock to the I2S source (as done by clockgen.xc for SPDIF & ADAT) either on it's own or by integrating with clockgen.

Can't you just add a counter and port toggle in the restart_check() callback method? I have done this many times to achieve exactly what you describe to recover the clock from external I2S masters.
User avatar
SirShagsalot
Member
Posts: 10
Joined: Fri Aug 04, 2017 4:33 am

Postby SirShagsalot » Thu Aug 10, 2017 8:02 am

Hi,

infiniteimprobability wrote:The reason for this is that all CODECs/DSPs we have been requested to interfaced to support 32b. It also happens to be a native serdes size for the buffered mode of a 1b port.


We use SOC's (Bluetooth, Wifi etc.) to extend the capabilities of our products and would like to be able to use I2S from them, as some offer no SPDIF or require massive code base changes to enable SPDIF out.

For some reason these systems (at least the ones we have so far seen) make the bitclock exactly the number of actual bits of the datastream. As only 16 & 24 Bit are available in playable files, the I2S slave should transparently support 16/24/32 BCK per sample and a wordlength of 16/24/32 Bit respectively, with a 32 Bit sample output for further processing within XMOS.

We have implemented and testing a workaround on the I2S slave library. It now (for us) reliably works at 16/24/32 Bit but for now struggles with quad speed I2S, so more work is needed.

infiniteimprobability wrote:Can't you just add a counter and port toggle in the restart_check() callback method? I have done this many times to achieve exactly what you describe to recover the clock from external I2S masters.


Yes, one of the reasons why we'd like to use clockgen is that we use SPDIF input anyway so piping I2S samples into this instead of SPDIF samples avoids duplication and much code change. Overall we have gotten things mostly to work.

Greez SSAL

(as in Greetings from Sir Shags A Lot)
User avatar
SirShagsalot
Member
Posts: 10
Joined: Fri Aug 04, 2017 4:33 am

Postby SirShagsalot » Thu Aug 10, 2017 8:18 am

PS, love your Avatar!
User avatar
infiniteimprobability
XCore Expert
Posts: 886
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Fri Aug 11, 2017 9:13 am

For some reason these systems (at least the ones we have so far seen) make the bitclock exactly the number of actual bits of the datastream.


Can you give examples (part numbers?) - We should at the very minimum add a feature request to the library with supporting data.

We have implemented and testing a workaround on the I2S slave library. It now (for us) reliably works at 16/24/32 Bit but for now struggles with quad speed I2S, so more work is needed.

That's good. This is one of the reasons why we ship source.. Are you using partout/partin? Feel free to post stuff here for ideas/workarounds

PS, love your Avatar!

Cheers - not my cat but if I find one that does that I will offer to buy it!
User avatar
SirShagsalot
Member
Posts: 10
Joined: Fri Aug 04, 2017 4:33 am

Postby SirShagsalot » Fri Aug 11, 2017 11:02 am

Hi,

infiniteimprobability wrote:Can you give examples (part numbers?) - We should at the very minimum add a feature request to the library with supporting data.


I am not sure I can give part numbers, we buy in completed modules under NDA.

Generically speaking some devices are based on Router IC's by Mediatek, Atheros & Qualcomm (e.g. Qualcomms Allplay Module) and CSR/Qualcomm Bluetooth IC. Others exist.

Most often these systems work only as I2S master and equally often omit a MCK...

infiniteimprobability wrote:That's good. This is one of the reasons why we ship source.. Are you using partout/partin? Feel free to post stuff here for ideas/workarounds


We reduced the buffer size and analyse wck/bck ratio to set things. At Quad speed we do get all the data, but it is scrambled... I think our timing problem is that same undocumented feature we found previously with I2C outputs where clock edges do not align.

Greez SSAL
User avatar
SirShagsalot
Member
Posts: 10
Joined: Fri Aug 04, 2017 4:33 am

Postby SirShagsalot » Mon Aug 14, 2017 8:50 am

Hi,

SirShagsalot wrote:At Quad speed we do get all the data, but it is scrambled... I think our timing problem is that same undocumented feature we found previously with I2C outputs where clock edges do not align.


That was it.

The timing of the (bitbanged?) I2S from the Network audio module was already not perfect, so together with the I2S slave timing shift we were outside the timing window.

Greez SSAL
User avatar
SirShagsalot
Member
Posts: 10
Joined: Fri Aug 04, 2017 4:33 am

Postby SirShagsalot » Tue Aug 15, 2017 11:33 am

Hi,

infiniteimprobability wrote:FYI - Bug/Feature request logged:
https://github.com/xmos/lib_i2s/issues/33


Thank you. We figured it ourselves, but someone at XMOS may do a much better job than we did. Do watch the timing robustness - it is possible to get I2S at way > 192kHz and I would not expect the I2S source to have clean timing...

Let's hope that this request receives an "infinite improbably" chance of being dealt with soon and gives us a robust solution.

Greez SSAL

Return to “Applications”

Who is online

Users browsing this forum: No registered users and 10 guests