Is it possible to interface with I2S devices?

I've been looking at some I2S DACs lately, but I'm concerned that I won't b able to interface with them. I can't seem to find much about I2S here, just one bit about how the DUE has it built in, and I recall Paul Stoffregen mentioning that getting I2S to work with the Teensy 3.0 was a pain because of the clock signals or something.

When I look at the datasheets though, the interface doesn't seem that complicated. There appears to be three data lines, two of which are clock signals, and one clock signal is the bit clock and is 16, 32, or 64x that of the main clock. So I guess the main clock signals the end of an integer or whatever. Seems simple enough to bit bang if there were no other way of generating the signal.

So what's the issue? What am I missing here? Or am I worrying over nothing?

Can you post links to datasheets? (not familiar with the devices)

Well, here's one for example: http://www.ti.com/lit/ds/symlink/pcm1753.pdf

I2S is a standard means of talking to audio hardware. There are variations on it, like "left justified" which are supposed to be easier to interface with.

I also found this very informative document on it: http://www.ti.com/lit/an/slaa449a/slaa449a.pdf

That particular DAC above is 24 bit, which may be a bit much, but 16 bit per channel exists as well.

The second link shows very clearly how the bit stream should look like.

Google for the soft SPI library - to see how to set up a library for such a protocol.

I know what the bit stream looks like. My question was - Others have reported issues with meeting the requirements of this protocol and it sounds like it has some kind of strict timing issue.

I did some more searching and I found a bunch of discussions about it. But I'm still not 100% clear on it. One issue seems to be that with the standard I2S protocol you have to toggle the LR clock before you send the last bit so that causes problems if you want to use hardware SPI to do the transfer. But there seems to be a left-justified format that might work. But, if you were doing DMA like Paul does on his boards, then maybe again you would have a problem toggling that second clock line at the right times. There is also the issue of timing and how tolerant the chips are of any transfer delays and whatnot. That I'm completely uncertain about.

Anyway, it seems anything but straightforward.

scswift:
I know what the bit stream looks like. My question was - Others have reported issues with meeting the requirements of this protocol and it sounds like it has some kind of strict timing issue.

The second PDF shows the sender has to provide a clock signal,

So sending two16 bit ints becomes something like

void send2ints(int left; int right)
{
  digitalWrite(LRCLK, LOW);
  for (byte i=0; i < 16; i++) 
  {
    digitalWrite(DOUT, left & ( 1 << i));
    digitalWrite(BCLK, HIGH);
    digitalWrite(BCLK, LOW
  );
  digitalWrite(LRCLK, LOW);
  for (byte i=0; i < 16; i++) 
  {
    digitalWrite(DOUT, right & ( 1 << i));
    digitalWrite(BCLK, HIGH);
    digitalWrite(BCLK, LOW
  }
);

if timing does not meet the requirements, it can be done with direct port manipulation, way faster less portable.
and of course if too fast, use delaymicroseconds to slow it down.