Retro Lite CM4: Handheld Gaming Console

[StonedEdge]

Hi there everyone.

I am very new to Raspberry Pi and have been dragged into the scene by my friend who wants to take advantage of the latest computing power provided by the newer processor of the Compute Module 4 (BCM2711). I do not have much experience with the Raspberry Pi, but I wanted to post my project goals here in the hope that someone who has more experience than I do tell us whether or not it is feasible or not. I'm excited, and I hope you are too!

I am yet to read through the Compute Module 4 datasheet or the BCM2711 peripherals datasheets, which I am sure will answer a lot of my questions. I am familiar with C programming and have done quite a lot of projects with Microchip's PIC 8-bit microcontrollers (including setting up PD profiles for USB-C PD negotiation, power management with various chips from TI (BQ series) and more.)

This is what we have planned for our project (pictures included):



- 5" LCD IPS screen (displaying 24-bit parallel RGB interface if possible. Probably will settle for 18-bit parallel as I am not sure entirely if we will have enough pins left for i2s audio amplification. I am assuming here that the Compute Module 4 will require the basic 4 signal lines (serial clock, word clock, serial data and master clock. My question here is whether this would even be possible given that the DPI signal requires a large amount of pins, not leaving much available for i2s. Not entirely sure if the Pi has analog outputs for audio signals.)
- Dual Switch Joysticks
- Stereo speakers
- Resin Cast buttons and dpad
- Anodized aluminum housing
- Custom aluminum heatsink and fan
- Raspberry Pi CM4
- AIO (all-in-one) PCB including arduino (for control input), battery management (bq24292i from Texas Instruments, controlled over i2c via the PIC16F15234 - don't think using the Pi i2c would be ideal as this chip needs to be continuously powered by the battery voltage (VSYS)), - - - Backlight boost converter circuitry
- USB C Charging (STUSB4500) and internal data switching (assuming the Pi4 uses USB 3.0 signals? I've only dealt with USB 2.0 before, so I'll have to learn how to impedance match for 3.0 signals on our AIO PCB (most likely 4 layer PCB).
- External HDMI output
- 4000mah lithium polymer cell

Does all of this seem feasible with a CM4 Raspberry Pi module? I suppose my main question at this point would be confirming whether i2s audio amplification/24-to-18 bit DPI interfacing is possible or if I'll need to select one or the other or go with analog audio.

Sorry for all of the questions. A big Raspberry Pi noob here but coming into this project with a good coding background. It goes without saying I will be diving into the datasheets for the processor and the CM4 module itself, but if anyone could steer me in the right direction, that would be great.

Looking forward to updating everyone here often! The case design was done in Solidworks, if anyone was wondering and will be CNC machined out of billet aluminum.

[fruitoftheloom]

Hi there everyone.

I am very new to Raspberry Pi and have been dragged into the scene by my friend who wants to take advantage of the latest computing power provided by the newer processor of the Compute Module 4 (BCM2711). I do not have much experience with the Raspberry Pi, but I wanted to post my project goals here in the hope that someone who has more experience than I do tell us whether or not it is feasible or not.

I am yet to read through the Compute Module 4 datasheet or the BCM2711 peripherals datasheets, which I am sure will answer a lot of my questions. I am familiar with C programming and have done quite a lot of projects with Microchip's PIC 8-bit microcontrollers (including setting up PD profiles for USB-C PD negotiation, power management with various chips from TI (BQ series) and more.

This is what we have planned for our project (pictures included):



- 5 - 5.5" LCD IPS screen (displaying 24-bit parallel RGB interface if possible. Probably will settle for 18-bit parallel as I am not sure entirely if we will have enough pins left for i2s audio amplification. I am assuming here that the Compute Module 4 will require the basic 4 signal lines (serial clock, word clock, serial data and master clock. My question here is whether this would even be possible given that the DPI signal requires a large amount of pins, not leaving much available for i2s. Not entirely sure if the Pi has analog outputs for audio signals.)
- Dual Switch Joysticks
- Stereo speakers
- Resin Cast buttons and dpad
- Anodized aluminum housing
- Custom Copper Heatsink and fan
- Raspberry Pi CM4
- AIO (all-in-one) PCB including arduino (for control input), battery management (bq24292i from Texas Instruments, controlled over i2c via the PIC16F15234 - don't think using the Pi i2c would be ideal as this chip needs to be continuously powered by the battery voltage (VSYS)), - - - Backlight boost converter circuitry
- USB C Charging (STUSB4500) and internal data switching (assuming the Pi4 uses USB 3.0 signals? I've only dealt with USB 2.0 before, so I'll have to learn how to impedance match for 3.0 signals on our AIO PCB (most likely 4 layer PCB).
- External HDMI output
- 4000mah lithium polymer cell

Does all of this seem feasible with a CM4 Raspberry Pi module? I suppose my main question at this point would be confirming whether i2s audio amplification/24-to-18 bit DPI interfacing is possible or if I'll need to select one or the other or go with analog audio.

Sorry for all of the questions. A big Raspberry Pi noob here but coming into this project with a good coding background. It goes without saying I will be diving into the datasheets for the processor and the CM4 module itself, but if anyone could steer me in the right direction, that would be great.

Looking forward to updating everyone here often! The case design was done in Solidworks, if anyone was wondering and will be CNC machined out of billet aluminum.

The BCM2711 SoC is the heart of the Raspberry Pi 4B which has been out for 18 months, so lots of information and projects etcetera...

[Imperf3kt]

It should be possible but it does not sound cheap at all.
Do you have a BOM and tooling costs for this project? Do you intend to sell these devices?

[trejan]

- 5 - 5.5" LCD IPS screen (displaying 24-bit parallel RGB interface if possible. Probably will settle for 18-bit parallel as I am not sure entirely if we will have enough pins left for i2s audio amplification.

You can't use DPI and I2S together. I2S output needs 18/19/21 but none of the available DPI modes has those 3 GPIOs spare. RGB565 is possible if you're okay to lose the least significant bit of the red channel but it won't look very good.

If you're okay with PWM audio like the model A/B Pi boards then you can use RGB666.

- USB C Charging (STUSB4500) and internal data switching (assuming the Pi4 uses USB 3.0 signals? I've only dealt with USB 2.0 before, so I'll have to learn how to impedance match for 3.0 signals on our AIO PCB (most likely 4 layer PCB).

The SoC has a USB 2.0 OTG controller built into it. The Pi 4 has USB 3.0 because it has a USB 3.0 controller attached via PCIe.

[MikeDB]

Hi there everyone.
....

Does all of this seem feasible with a CM4 Raspberry Pi module? I suppose my main question at this point would be confirming whether i2s audio amplification/24-to-18 bit DPI interfacing is possible or if I'll need to select one or the other or go with analog audio.

Another possibility is to use the pins for DPI, but then use SPI or even bit-banging to attach a cheap external MCU with I2S which deals with a DAC or CODEC itself. The Pi doesn't have a decent MCLK anyway which tends to limit your choice of device anyway (usually to the PCM 5102).

[cleverca22]

The Pi doesn't have a decent MCLK anyway which tends to limit your choice of device anyway (usually to the PCM 5102).

are you refering to the jitter from the MASH filter? that can be avoided if you stick to integer division, and mess with the PLL more, but ive not investigated if the firmware can be told to do so


as for the question OP has:
DPI uses gpio 0-27, but some pins can be skipped depending on the display and desired color depth
I2S uses either gpio 18-21 or 28-31 or 50-53
50-53 arent available, because the foundation decided to stick a gigabit ethernet PHY on the base CM4, leaving the user with no choice on those pins
28-31 arent available, because the CM4 only exposes 0-27, so a full DPI would use every single gpio on the entire module

i think there is one i2c bus outside of the 0-27 range, that you could use, but the documents are not clear on which pins are being used

the official touchscreen is just using a DSI->DPI bridge chip, that would only use 2 GPIO pins (an i2c bus to manage it), and the rest is all on the DSI port, you can also just design your own board with the same idea

the usb3.0 ports came from the vl805 pci-e chip, but the CM4 lacks that, so you only have a single usb2.0 to deal with

since you have experience with PD, that opens up some useful charging options
you can request as much voltage as you can handle, then buck-regulator it down to 5v for the CM4, and ~3.7v for the lipo charging, and get more watts then 5v alone would have allowed

if you have your own dedicated chip/uC for the usb-c negotiation stuff, you can proxy the host/device state to the CM4's older USB_OTG pin, and then get proper host/device role selection with tue usb-c cable (something the rpi4b cant do)


comparing https://elinux.org/RPi_BCM2711_GPIOs and https://www.raspberrypi.org/documentati ... /README.md
i can see that mode 4 (RGB565) would get you gpio 18-20 free, but thats i2s input not i2s output
no dpi mode would give you the right pin combinations to get i2s on 18-21, and duplicate instances of those signals arent routed anywhere i know of

definitely looks like either a dsi or an hdmi(yuck) display would be your only viable solution, if you want i2s

however, gpio 18/19 might get you pwm audio (unknown if the firmware can switch pwm controllers)
and dpi modes 3, 4, and 6 (565 and 666) leave 18/19 free for PWM audio
that then leaves some other pins (25-27, 20,26,27 or 26-27) open, which you could use to bit-bang something to the uC, or reuse the extra i2c bus that isnt on 0-27

[StonedEdge]

It should be possible but it does not sound cheap at all.
Do you have a BOM and tooling costs for this project? Do you intend to sell these devices?

We don't really have a BOM yet but my friend is doing all of the machining work since he has his own 3-axis milling machine he designed himself, so that rules out any ridiculous costs for the housing if we were to go with a production house. I don't plan on selling these yet. That has not even crossed our minds. We first do these projects for fun, not for profit.

The SoC has a USB 2.0 OTG controller built into it. The Pi 4 has USB 3.0 because it has a USB 3.0 controller attached via PCIe.

Ah okay, thanks for the clarification. I plan on having some sort of internal muxing going on, most likely with the TS3USB2221A IC, since that's the easiest implementation wise for USB 2.0 data switching (at least I have used it with success).

You can't use DPI and I2S together. I2S output needs 18/19/21 but none of the available DPI modes has those 3 GPIOs spare. RGB565 is possible if you're okay to lose the least significant bit of the red channel but it won't look very good.

If you're okay with PWM audio like the model A/B Pi boards then you can use RGB666.

Okay, as I thought i2s audio is going to be difficult if I want to drive the screen with the parallel interface. Is there analog audio output channels that I could use for the CM4 to drive an analog audio amplifier instead of doing i2s? The bit-banging idea could also work that you suggested.

I might as well add here some of the other nice "features" that I would like to try to implement. There is no real timeline/deadline for this project to be done, and I would consider this feature to be "nice to have" but not really necessary, particularly when I can just output digital video to a TV directly through a micro/standard HDMI connector. The added complexity doesn't really seem worth it, but if I can learn something new I'd like to give it a try with some help here of course

I've been looking into USB-C alternate modes and noticed that TI makes a nice little chip for doing muxing (TUSB546A). Since the Raspberry Pi CM4 outputs native HDMI 2.0, I thought it would be cool to take advantage of that and output HDMI 1.4b protocol over the USB-C port connector pins as well as PD. You can read more about it here. Currently, I would hope to just port over the PD IC controller I am using which is programmed over i2c via its NVM (which allows up to two PD profiles and on-the-fly PD capabilities if connected to an i2c master). I don't think it handles alternate modes though... right now the plan is to output either 12v/2A (24W) or 9v/3A (27W) and buck that down to 5V to power the Pi from USB port. When powered from batteries, I will use a 5V boost converter, although I'm yet to find anything that can handle the current draw of the CM4 yet.

I'd be interested to hear if anyone has tried to use the above linear redriver IC for HDMI output source-sink setup before. It looks like it's entirely configurable in hardware (via GPIOs) or software (i2c) so it certainly seems feasible... although not easy at all. Looks like I'll need the muxing IC, a compatible PD controller (not the one I had planned on using, that being the STUSB4500) and another muxer for the SBU1/2 pins for carrying the HEAC+/- signals for HDMI as well.

Application notes (HDMI over USB-C using the TUSB546A): https://www.ti.com/lit/an/slla333/slla333.pdf
Datasheet (TUSB546A): https://www.ti.com/lit/ds/symlink/hd3ss ... e.com%252F
Datasheet (STUBS4500): https://www.st.com/resource/en/datasheet/stusb4500.pdf

[cleverca22]

one thing ive noticed with hdmi over usb-c, is that there isnt enough pins for the hotplug, cec, and EDID-eeprom pins

those instead get wrapped up in packets over the USB-C negotiation protocol, and the TI chip then has to un-wrap those signals, and then emulate the old interface for the SoC to play along
if it cant emulate EDID, then the drm/hdmi stack in linux would have to be patched, to know how to talk to the TI chip, and query the remote EDID

Okay, as I thought i2s audio is going to be difficult if I want to drive the screen with the parallel interface. Is there analog audio output channels that I could use for the CM4 to drive an analog audio amplifier instead of doing i2s? The bit-banging idea could also work that you suggested.

PWM audio should be possible, as i listed ~2 posts above

[StonedEdge]

one thing ive noticed with hdmi over usb-c, is that there isnt enough pins for the hotplug, cec, and EDID-eeprom pins

Are you sure about that? Looks like there is enough pins for HDMI 1.4b protocol

[trejan]

Is there analog audio output channels that I could use for the CM4 to drive an analog audio amplifier instead of doing i2s?

There aren't any DAC outputs on the Pi SoC or CM. The Pi model A/B do it by using the PWM peripheral and a low pass filter. Lots of people complain about it but it isn't as bad as everybody makes out and I think it would be sufficient for a handheld but decide for yourself.

another muxer for the SBU1/2 pins for carrying the HEAC+/- signals for HDMI as well.

The Pi SoC doesn't support HEAC.

Are you sure about that? Looks like there is enough pins for HDMI 1.4b protocol

The wikipedia article has a decent explanation.

[cleverca22]

one thing ive noticed with hdmi over usb-c, is that there isnt enough pins for the hotplug, cec, and EDID-eeprom pins

Are you sure about that? Looks like there is enough pins for HDMI 1.4b protocol

yeah, its right there in the graphic, pin A5/CC, its doing the job of 3 different pins: SCL/SDA, the EDID eeprom, and CEC a one-wire bus

the chip managing CC (which also deals with PD negotiation?) has to support the CEC/EDID protocol, and then either proxy it to the SoC and have drivers or emulate the normal hdmi signals so the existing drivers dont notice a difference

[StonedEdge]

the chip managing CC (which also deals with PD negotiation?) has to support the CEC/EDID protocol, and then either proxy it to the SoC and have drivers or emulate the normal hdmi signals so the existing drivers dont notice a difference

Yup, it looks like you need a specific chip that handles everything, including the alternate mode negotiation/PD etc all-in-one. I think I will just pop a HDMI breakout next to the USB-C port and call it a day. Too complicated to try and do all the negotiation with a dock similar to the Nintendo Switch, and just doesn't really seem worth it. Even if I get the alternate modes working from a USB-C to HDMI cable, I'd still somehow have to negotiate a power contract as well to charge it from the sink side. I think it's way more complicated than I originally thought.

[cleverca22]

the chip managing CC (which also deals with PD negotiation?) has to support the CEC/EDID protocol, and then either proxy it to the SoC and have drivers or emulate the normal hdmi signals so the existing drivers dont notice a difference

Yup, it looks like you need a specific chip that handles everything, including the alternate mode negotiation/PD etc all-in-one. I think I will just pop a HDMI breakout next to the USB-C port and call it a day. Too complicated to try and do all the negotiation with a dock similar to the Switch, and just doesn't really seem worth it.

if the specs are known, it should be possible to handle it with something like an arduino
i'm also curious as to how complex it is to implement it all...

edit1:
oh, and you also dont even have to worry about the plug being inserted upsidedown with reguard to the hdmi lanes

its not documented properly, but the HDMI output on the pi4, can fully swap all 4 differential pairs in its PHY
so with a custom driver, you could detect the usb-c being plugged in "wrong", and then inform the hdmi driver to flip the pairs, so the signal still works

edit2:
having read one doc on usb-pd, i can see that there is only a single CC path between the 2 devices
if neither end is flipped, its just CC1<->CC1
if there is a single flip, it may be either CC1<->CC2 or CC2<->CC1
and if both ends are flipped, it becomes CC2<->CC2

in all cases, the power source has a pull-up resistor, and the power sink has a pull-down, and the active CC line forms a voltage divider, to signal both roles and cable twist
once you know the twist, you could configure the HDMI PHY to un-twist things, however, i think you need to participate in the digital CC protocol (havent read up on it yet), to confirm both ends agree to hdmi first

the digital CC protocol is also used to negotiate a higher voltage on the main VBUS pins

edit3:
https://www.embedded.com/usb-type-c-and ... -protocol/
it looks like anything beyond the dumb (pullup+down) negotiation, requires an e-marked cable
you then exchange packets of at least 32bits (+32bit crc) between each party (the display, the video source, and the cable), and then agree on things like alternate modes or higher voltage
it looks fairly simple so far, and an arduino or any other uC could implement it (its only 300k baud)
using the AVR i2c slave, you can then emulate the EDID eeprom, and proxy things over the PD protocol, so the SoC wont even know that USB-C is going on

but you will need either some muxing to un-swap the hdmi lanes when the plug is in upsidedown
or a special driver to inform linux that its upsidedown, and the PHY has to swap them within the SoC

[cleverca22]

Screenshot_2020-10-30_06-27-24.png (79.45 KiB) Viewed 23632 times

from over at https://www.ti.com/lit/an/slla333/slla333.pdf

it looks like the "PD Controller" chip is dealing with the EDID emulation i mentioned (the DDC lines)
and then the TUSBx46 deals with switching between usb3 (you wont have that) or hdmi, and possibly also dealing with the plug being upsidedown (which could be handled in the CM4, with kernel changes)

[StonedEdge]

Yep, that's exactly what is happening. It doesn't look like the standalone PD controller I was planning on porting over from other projects (STUBS4500) is going to work, so I need to try and find a suitable PD controller that is compatible with HDMI over USB-C (or DisplayPort) for setting up alternate modes via communication over the CC lines. Unless you think I can use the STUSB4500, but it's not looking too good. I really don't want to have to setup another entire PD controller if I don't have to (the STUSB4500 was relatively easy but still a nightmare to configure all of the PDOs). Cypress make some really good ones, but they are not that easy to work with. Specifically, the Cypress CCG2 series CYPD2120 looks like its only a 24 pin QFN and would do the job well. Programming it looks like a pain, though.

If you have any other solutions I'd be open to them though!

[cleverca22]

Yep, that's exactly what is happening. It doesn't look like the standalone PD controller I was planning on porting over from other projects (STUBS4500) is going to work, so I need to try and find a suitable PD controller that is compatible with HDMI over USB-C (or DisplayPort) for setting up alternate modes via communication over the CC lines. Unless you think I can use the STUSB4500, but it's not looking too good. I really don't want to have to setup another entire PD controller if I don't have to (the STUSB4500 was relatively easy but still a nightmare to configure all of the PDOs). Cypress make some really good ones, but they are not that easy to work with. Specifically, the Cypress CCG2 series CYPD2120 looks like its only a 24 pin QFN and would do the job well. Programming it looks like a pain, though.

If you have any other solutions I'd be open to them though!

https://www.embedded.com/usb-type-c-and ... -protocol/
this page has an overview of the actual PD protocol

All PD messages are transmitted at 300KHz +/- 10% over the CC line. The first 64 bits (Preamble ) are an alternating 1, 0 pattern so that the receiver can synchronize with the actual transmitted clock. The next 16-bit word (Address or Type ), contains the message address, indicating the message recipient or other type information (SOP* communication explained below). The next 16-bit field contains the message header, which is encoded as shown in Figure 9.

if we can find a source with the finer details. it should be possible to just implement this on any uC

[cleverca22]

1: https://www.usb.org/document-library/usb-power-delivery
2: https://www.ti.com/product/TPS65982

1 is the full specs i had been searching for
2 looks like a chip capable of dealing with the PD protocol for us, but also capable of doing hdmi altmode switching

[StonedEdge]

Hi guys.

Couple of updates on the CM4 project - I have not posted in a while so sorry about that, but I guarantee that I have been working on this in my down time with my friend. We are struggling a little bit deciding on an i2s audio amplifier solution that can drive both headphones and speaker at correct gain. As far as I can tell, most "open-sourced" audio amplifier solutions are either mono or stereo but do not have independent gain control for either headphones or speakers, meaning that I would most likely blow out my headphones. The LM49450 seems like a good solution (fully controllable over i2c pins) with two separate 32-step volume controls, one for the speaker channels and one for the headphone channels. This means that I could adjust the gain of the headphone and speakers to be set independently of each other.

I was wondering if anyone had used this amplifier before and has any resources I could use, or if there is any other solutions out there for the Pi for digital audio output. The LM49450 DAC unfortunately cannot generate its own MCLK signal however, so I would need to add on an external PLL to generate the signal.

Here's a couple more pictures of progress. We finished the CAD work together to replicate the switch lite as much as possible. My friend machined the front side of the case out of a leftover acrylic block he had and we ordered a lot of the PCBs from JLCPCB. I have been working on the PCB design in eagle as well in my spare time.

If anyone has any ideas on what the most "simple" solution would be, please do let me know, I'm open to all suggestions.

[Gavinmc42]

You can use a HDMI to LCD interface chip.
https://www.adafruit.com/product/1928

Waveshare have LCD modules with these on them now
One example
https://www.waveshare.com/product/displ ... -lcd-h.htm

GamePi
https://www.waveshare.com/product/raspb ... me-hat.htm

No need for driver for HDMI.

[MikeDB]

I was wondering if anyone had used this amplifier before and has any resources I could use, or if there is any other solutions out there for the Pi for digital audio output. The LM49450 DAC unfortunately cannot generate its own MCLK signal however, so I would need to add on an external PLL to generate the signal.

No need for a PLL. Use a 12.288MHz crystal oscillator (several on the JLCPCB site such as C70515) to feed the LM49450 and make that the master, putting the I2S pins on the CM4 into slave mode.

[StonedEdge]

No need for a PLL. Use a 12.288MHz crystal oscillator (several on the JLCPCB site such as C70515) to feed the LM49450 and make that the master, putting the I2S pins on the CM4 into slave mode.

Thanks for your reply. How would I attach that to the LM49450? This is the current schematic setup I have - I've pulled this from another project but I assume I would just connect the oscillator to pin 8?

[MikeDB]

I assume I would just connect the oscillator to pin 8?

Yes. The oscillators have CMOS logic outputs so will drive MCLK pin 8 fine. Check if the oscillator you use needs a pullup - some do, some don't.
Then use the CM4 to program its I2S port to slave and the LM49450 to master in the I2S Clock register

[StonedEdge]

Yes. The oscillators have CMOS logic outputs so will drive MCLK pin 8 fine. Check if the oscillator you use needs a pullup - some do, some don't.
Then use the CM4 to program its I2S port to slave and the LM49450 to master in the I2S Clock register

Not sure if that is going to work actually - as mentioned in the datasheet of the LM49450 (page 22) here:
EDIT: Unless you mean setting the I2S CLOCK REGISTER (0x04h) B0:B3 bits high so that the LM49450 generates the WS signals? I think I was getting confused with i2c haha.

"The LM49450 is controlled through an I2C-compatible serial interface that consists of a serial data line (SDA) and a serial clock (SCL). The clock line is uni-directional. The data line is bi-directional (open collector). The LM49450 and the master can communicate at clock rates up to 400kHz. Figure 65 shows the I2C interface timing diagram. Data on the SDA line must be stable during the HIGH period of SCL. The LM49450 is a transmit/receive slave only device, reliant upon the master to generate the SCL signal. Each transmission sequence is framed by a START condition and a STOP condition (Figure 66). Each data word, register address and register data, transmitted over the bus is 8 bits long as is always followed by and acknowledge pulse (Figure 67)."

[MikeDB]

Yes. The oscillators have CMOS logic outputs so will drive MCLK pin 8 fine. Check if the oscillator you use needs a pullup - some do, some don't.
Then use the CM4 to program its I2S port to slave and the LM49450 to master in the I2S Clock register

Not sure if that is going to work actually - as mentioned in the datasheet of the LM49450 (page 22) here:

"The LM49450 is controlled through an I2C-compatible serial interface that consists of a serial data line (SDA) and a serial clock (SCL). The clock line is uni-directional. The data line is bi-directional (open collector). The LM49450 and the master can communicate at clock rates up to 400kHz. Figure 65 shows the I2C interface timing diagram. Data on the SDA line must be stable during the HIGH period of SCL. The LM49450 is a transmit/receive slave only device, reliant upon the master to generate the SCL signal. Each transmission sequence is framed by a START condition and a STOP condition (Figure 66). Each data word, register address and register data, transmitted over the bus is 8 bits long as is always followed by and acknowledge pulse (Figure 67)."

That's the I2C interface where the Pi will be master. I2S is totally separate and it's normal to put the Pi into slave mode on that since it's so crippled by normal audio standards.

Page 26 heading I2S Clock control ".....and word select clock in master mode"

[StonedEdge]

That's the I2C interface where the Pi will be master. I2S is totally separate and it's normal to put the Pi into slave mode on that since it's so crippled by normal audio standards.

Page 26 heading I2S Clock control ".....and word select clock in master mode"

Ah, thanks Mike. Just noticed that now. Alright. Let me see if I can find the appropriate oscillator for the job. As you mentioned the Pi will be master. I haven't actually programmed a Pi before (mainly just PIC/ESP32 stuff) but I am hoping basic button debouncing for volume control will be easy enough. Thank you for your advice and help.