To expand on what Paul said:
I2C is the simplest. It is a shared bus system (much like the old party line telephones used in rural areas) where each device has an address. The master (Teensy) sends out a message with an address to a specific device, and the device replies. To keep things simple, you need to make sure the OLED screen's i2c addresses don't conflict with the i2c addresses on the audio board. The audio board uses two addresses:
- SGTL5000 at address 0x0A
- WM8731 at address 0x1A
If you did not include the audio board on your Teensy, you might need to add 2 2.2K pull-up resistors (one resistor between pin 18/A4/SDA and 3.3v and the other resistor between pin 19/A5/SCL and 3.3v). The audio board includes these pull-up resistors, so you don't need to worry about them.
SPI is perhaps a faster bus speed. It has 3 shared pins (MOSI typically on pin 11, MISO typically on pin 12, and SCK typically on pin 13). Each SPI device has 1 or 2 additional pins that are unique to that device. One pin is CS (for chip select) that when set high or low (depending on the device) indicates that the master is talking to that device. There is a second pin that many SPI devices have (DC) that tells the device whether the master is sending command bits or data bits. Some devices can have additional pins as well. For example, many OLED/TFT devices have a separate pin for reseting the device.
Now due to needing to use I2S to read/write digital audio data, the Audio board needs to change MOSI and SCK to be on their alternate pins. The alternate pin for MOSI is pin 7, and the alternate pin for SCK is pin 14/A0. To be pedantic, the alternate pin for MISO is pin 8, but the audio library does not need to change this pin.
If you are taking random SPI code off the inter-tubes, it may/may not have added SPI transaction support. See the SPI page above for more details.
For some display devices, there is an extra speed up if you can use specific CS and DC pins in libraries provided by the Teensy release. It is probably better to ask for a particular device if there are specific Teensy optimizations.
I have discovered that if I use the Teensy 3.5 and 3.6 at high clock speeds, some display devices (mostly the 128x128 TFT or OLED screens) don't work too well, and I have to tune the code to reduce the SPI bus speed to prevent the device from getting data faster than it can accept.
So, I would suggest try out one of the 32x128 or 64x128 OLED i2c devices and see if it is fast enough for your needs. If it is not fast enough, then you can look at going to SPI devices and some of the hair that that involves.
There is another alternative that is not i2c or spi. The maker dig-ole has a series of displays that can use either i2c, spi, or one of the serial UARTs (i.e. Serial0, Serial1, Serial2). You have to import their library. When I did this years ago, I needed to add a line or two for Teensy support. The default is to use a Serial UART, which means using just one data wire + 3.3v/ground. Dig-ole also has TFT LCD modules (OLED tends to be brighter and viewable from more angles, but the older TFT can run faster, and is available in different sizes):
When choosing a display, it will simplify your life if the display can run off of 3.3v power instead of needing 5v power.
<edit>
One interesting OLED device is a 32x128 bit display that mounts on top of the Teensy from Sparkfun. It has various solder jumpers to control which pins to use:
<edit2>
Some SPI displays don't have a MISO pin, because the display never returns any information (MOSI is used to send data to the display from the Teensy, MISO is used to send data to the Teensy from the display, and SCLK is the clock signal).
Some SPI displays also have a micro-SD card reader with separate CS pins for the SD card. Given the audio board already has a micro-SD card reader, you don't have to connect those pins.
If you are running nearly out of memory, note that the i2c and SPI displays usually require you to have a copy of the screen in memory. When I was using the dig-ole displays, it was nice in that the display had the screen memory, and you just sent the screen commands (i.e. draw this line here, write this text there).
