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

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.

Implementors in "not having fully read standard" shocker!  :)

Actually, I suspect what's happened here is that whoever was designing
the chip needed a synced clock at 64fs for their DAC or ADC, noticed
that they could run the bitclock over speed to get that clock and
decided to use that.  Most devices use a separate MCLK.

> 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.

Broken and nonexistant are unfortunately not synonyms.  Like I say,
they're just using a subset of TDM mode configuration so it's not like
there's no possible use for this outside of workarounds anyway.

> But...

> Transmitter is sending 16 bits samples, and the receiver expecting 32
> bits samples. This is perfectly valid according to I2S, the receiver
> would append zeros to the LSBs of each sample.

> Now, what if the transmitter is using network mode? The receiver would
> interpret the 16 MSBs of the second slot as the 16 LSBs of the second
> channel on the first slot. This would be noisy. ;)

> I prefer to just not support network mode with I2S. I2S was designed to
> have a single transmitter and N receivers on the bus, or, in case of an
> I2S network have LRCLK assertion on all slots, which the PXA-SSP port
> can't do.

There's plenty of ways to mess up your audio if you do something broken,
I'm not overly concerned about this particular one over any of the
others so preserving the option to set it up seems useful.  As far as
your patch goes I think so long as it's clear how one would implement
I2S TDM it's fine, I don't think it's essential to implement it in your
patch since we don't have anything in-tree which needs it.

Personally I don't need this mode, the systems I'm working with all have
very much standards compliant CODECs which can be configured to use DSP
modes if desired.