[alsa-devel] [RFC] I2S and LEFT_J

[Eric Miao]

Daniel Ribeiro wrote:
> 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.

Daniel,

Could you give me an example of how can I setup the I2S in-compatible
mode with S_16LE, 64bitfs with your current patch? Thanks.