It says at
https://www.pjrc.com/teensy/gui/index.html?info=AudioInputI2S that the audio shield uses I2S, but at
https://www.pjrc.com/store/teensy3_audio.html the pin usage table for the Audio Adaptor says, "18, 19 (other I2C chips)" I'm assuming this is a typo
The audio shield uses both I2S and I2C.
I2S is used for the streaming of digital audio data. I2C is used for configuration. This is actually a very common setup for most audio codec chips with configurable parameters, because I2S doesn't provide any way to do configuration of settings, or really anything other than stream audio data.
I've never been able to understand "objects"
These "objects" are the pieces of software from the audio library. The idea behind an "object" is you can easily use it multiple times within a project. For example, there's a 4 channel mixer object. As you can see in part 2-2 of the
audio library tutorial, two of these mixers are used to combine sounds separate for the left and right channels. It's the exact same code implementing the mixer, but each processes different data. In object oriented lingo, these are called 2 "instances" of the object. The essence of objects is they are just pieces of software which can be easily reused multiple times, to process different data in each instance.
Most of the audio objects only manipulate data and do not access any hardware. You can create as many instances as you like, limited only by the available memory and CPU power to perform all the work they do. But the input and output objects are responsible for actually moving data to & from the outside world. They use hardware resources to do this, which means you can't use certain combinations because they would conflict when trying to access the same hardware. Ideally, the design tool would "know" about these hardware requirements and warn or prevent conflicting combinations. But today the best we have is documentation to tell you about these hardware dependencies.
I lost over, "S/PDIF output uses the I2S hardware.
It is a very cleaver hack that Frank created, to run the I2S at a faster rate and synthesize the S/PDIF bitstream in software.
the audio shield is I2S and it has both input and output (objects?), but the digital S/PDIF (I'm assumings is Toslink) is only found in the OUTPUTs. So again, I'm forced to ask, There can't be a S/PDIF input even if it is a I2S chip, because the audio shield (being I2S) has both INs and OUTs ?
Yes, the documentation is correct.
Frank's hack to get S/PDIF output is quite an amazing feat. But it does use the I2S hardware. When used in that mode, the input section of the I2S hardware is unused.
And is the S/PDIF only for optical, or is there a way I can use coax?
I believe it's the same signal, so you should only need to use a different circuit. I have not personally tried this, so I can't really comment on exactly what circuit to use. When/if you or anyone else figures it out and confirms a particular circuit works, I'd be happy to update the documentation.
To really make my head spin, I found another device
https://www.aliexpress.com/item/Aiy...PDIF-Fiber-Coaxial-USB-Sound/32833080360.html which claims to be I2S, but instead of 4 pins, it only has 3 [DATA, BCK, LRCK]
Many chips require MCLK, even though it's not technically part of the I2S protocol. Strictly speaking, I2S is only 3 signals.
Will this work as an I2S input?
Good question. Like many cheap Aliexpress products, it sorely lacking in technical documentation. It does at least say the signals are 1.8V logic, so at the very least you'll need 1.8V to 3.3V logic level conversion, with low enough propagation delay to work at the I2S speed. The
little bidirection level shifters using a mosfet and 2 resistors are absolutely not up to this fairly high speed task!
I2S is not a "plug and play" standard. There are many fine details to consider. The most basic point is whether a device is the I2S master (creates the clocks) or I2S slave (receives the clocks). Until very recently, the audio library used a BCLK to LRCLK ratio of 32. It was changed to a ratio of 64 earlier this year, because many chips seem to require this ratio, even if they only really support 16 bits. The newest generation of MEMS microphones with I2S were the main case people were finding.
Some time ago, there was a thread about using a I2S bluetooth board. It had better documentation, but still not as much or as clear as you might want. It might have used a FTDI chip, but I'm not sure. Anyway, after much fiddling and guesswork, it turned out that particular board couldn't support 44.1 kHz sample rate. Its I2S was limited to much slower speeds, which of course was not prominently mentioned in any of the documentation (remember, all datasheets are sales pitches).
Whether it will work is anyone's guess. Who knows, if you can figure out whether it's I2S master or slave mode and convert the logic levels, maybe it will work. Or maybe you'll run into tough problems.
I know this may be silly, but maybe try asking the seller for advice or more documentation. They probably won't know anything, or might reply with questionable info that's worse than just guessing, but if they do reply at all, I hope you'll share it here. It's always interesting to hear what those Chinese merchants answer about tech questions.
My final goal is to use this board as an input, and then have one Teensy output an optical signal which would be received by optical input on another Teensy and finally have the audio shield drive an analog amplifier.
There definitely isn't any S/PDIF input support. Frank tried to do input also, but it's just not feasible without hardware to recover the clock.
To get this working, at the very least you would need to make a S/PDIF to I2S converter. If you try to connect two different I2S devices, you'll need one to be the master and both of the others must be in slave mode (receiving the master's LRCLK and BCLK). If any require MCLK, you'll need to make sure that is the correct frequency and in phase with BCLK. Once you have all the clocks figured out so both sides share a valid BCLK and LRCLK, then getting data from one to another is just a matter of connecting a TX output or a RX input.