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

[Daniel Ribeiro]

Em Seg, 2009-06-15 às 16:04 +0100, Mark Brown escreveu:
> > For what it matters, the only difference on I2S/LEFT_J vs DSP_A/DSP_B
> > should be the SSPSFRM duration as it is needed to emulate the LRCLK.
> 
> Assuming no extra bit clocks.  Extra bit clocks do something different
> in I2S due to the fact that LRCLK falling edge is signifigcant.

Yes, assuming that we will not do the envelope thing.

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:

"It isn't necessary for the transmitter to know how many bits the
receiver can handle, nor does the receiver need to know how many bits
are being transmitted.

When the system word length is is greater than the transmitter word
length, the word is truncated (least significant data bits are set to
'0') for data transmission. If the receiver is sent more bits than its
word length, the bits after the LSB are ignored. On the other hand, if
the receiver is sent fewer bits than its word length, the missing bits
are set to zero internally. And so, the MSB has a fixed position,
whereas the position of the LSB depends on the word length. The
transmitter always sends the MSB of the next word one clock period after
the WS changes."


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.

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.

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

> > (and of course, the fact that I2S/LEFT_J are stereo only and that
> > network mode can't be supported)
> 
> You should be able to support at least modes using the first TDM
> timeslot I'd have thought.

Right, I2S/LEFT_J can be networked with DSP_A/DSP_B pcm formats, but
I2S/LEFT_J has to be the first slot.


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.

-- 
Daniel Ribeiro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem
 assinada digitalmente
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20090615/a7a44179/attachment.sig