Hi again,
I’m working on getting the PCM output directed through the IoT Connector. I’ve managed to succeed but there were a number of (very serious) errors in the documentation that I’ll correct here for future travelers.
General Background
The PCM output of your module can be routed either through an on-board codec or through the IoT connector. When it’s routed to the on-board codec, the codec outputs audio through the headset plug on the board.
The muxer is a TI chip TS3A5018 (datasheet: http://www.ti.com/lit/ds/symlink/ts3a5018.pdf). It is controlled by two inputs: EN which enabled any output and IN which selects which output. On my revision of the mangOH Red (Rev 6), EN is pulled low, which means things are enabled.
The input to the muxer (IN) is controlled by a GPIO expander (SX1509) that sits on an I2C bus that sits behind an I2C hub (TCA9546A).
RED ALERT
The mangOH Red Developer’s guide (here), states the following to switch the mux:
Populate / depopulate resistors on the Mux:
•R508 pulls signal low (default configuration)
•R520 pulls signal high (alternate configuration)
I succumbed to this bad guidance, got out my heat gun, desoldered R508, accidentally desoldered a nearby capacitor on the power line and then proceeded to lose the 0402 capacitor (it’s only 1mm x 0.5mm). At any rate, this guidance is wrong, don’t do any of this. It was already set up correctly. Hand soldering the 0402 back is near impossible so for the moment I’ve just shorted where the R508 resistor used to be and don’t have the regulating capacitor. Now I’m just bummed and frustrated that I followed directions 
Setting things up
For some reason the I2C hub wasn’t turned on by default with a stock SWI kernel (anyone know why?). Running i2cset -y 4 0x71 0x0f booted up the hub just fine. You can verify that is works by running the following:
root@swi-mdm9x28-wp:~# i2cdetect -y -r 4
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- 04 05 06 07 -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- UU -- -- -- 3e --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- 51 -- -- -- 55 -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- 6b -- -- -- --
70: -- 71 -- -- -- -- 76 --
You’ll notice that you see a device at 0x3e, which the GPIO Expander.
Next, you need to set up the (Expanded) GPIO13 connected to the PCM muxer’s IN line: gpioexp 1 13 enable
Now you can toggle the PCM muxer by doing one of the following:
gpioexp 1 13 output normal high # Sets PCM connected to onboard codec
gpioexp 1 13 output normal low # Sets PCM connected to IoT connector
You can test that this does something by testing an app that plays audio to the speaker and toggling the above commands, while listening to the audio jack and/or probing the IoT output with a logic analyzer.
Other notes
The GpioExpander service is broken and looks for the GPIO expander on a different bus (#7 rather than #4). You can fix it, but I haven’t tested that it exposes a valid interface.
What is le_audio_OpenPcmTx(…) supposed to do? Is it supposed to switch all of this stuff? as far as I can tell it doesn’t (based on logic probes)