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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
