[alsa-devel] [RFC] I2S and LEFT_J (was: ASoC: pxa-ssp: enhance I2S and add Left_J support)

[Daniel Mack]

On Mon, Jun 15, 2009 at 02:20:20PM -0300, Daniel Ribeiro wrote:
> But you have to consider that a codec that _requires_ 64 bits frames for
> 2*16bits I2S audio is not exactly I2S compliant.
> 
> Quoting the specifications:

[...]

Might be, but it's still up to the codec which further constrains it has
for the digital side :)

> Anyway, my interpretation of the I2S specifications, is that we don't
> need to do this enveloping thing at all. Codecs that requires this are
> simply broken, and are _not_ considering LRCLK edges as they are
> supposed to.

Quoting from the CS4270 datasheet:

5.1.2 Master/Slave Mode 
  The CS4270 supports operation in either Master Mode or Slave Mode. 

  In Master Mode, LRCK and SCLK are outputs and are synchronously
  generated on-chip. LRCK is equal to Fs and SCLK is equal to 64x Fs. 

  In Slave Mode, LRCK and SCLK are inputs, requiring external generation
  that is synchronous to MCLK. It is recommended that SCLK be 48x or 64x
  Fs to maximize system performance. 

I can only guess what really happens internally, but the most obvious
thing is that they need the additional clock cycles for internal
real-time processing.

> And finally, if the codec does this enveloping thing, it can't work if
> PXA is slave of LRCLK. The PXA-SSP port is definitely not I2S compliant,
> as it just ignores the LRCLK falling edge. We can workaround this using
> network mode with 4 slots and with slots 1|3 active, but this implies
> knowing the sample/frame width in advance, which by itself is an I2S
> spec violation.

Yes, that's true. For that very reason, we run the PXA in master mode,
but clock the whole SSP engine from the SSPEXTCLK pin. So the PXA is
master to LRCLK and BITCLK, but eventually it's still slave to an
external and tunable clock.

> I have hope that Daniel Mack's codec, which supposedly only works with
> 64 bits frames _is_ I2S compliant, and he just got to the wrong
> conclusion that it needs 64 bits frames after a lot of trial and error,
> and failing to fix the real issue. (setting 16bits frames(DataSize(16))
> for 2*16bit samples is simply wrong).

I'm willing to give that another try now that the codec is in slave
mode. But I fear there is some impact on the audio quality which I can't
quickly measure here, so I'd really vote for offering the mode I'm
currently using. Forbidding it due to API clearance even though it's
supported by the hardware is a step backwards.

Daniel