The mono path has no answer

[bdbarnett]

I2SOut converts to the wire's channel count, and a board with one transducer
on a two-slot wire gets the mic or the speaker in both. The ES7210 question on
the P4 is the same one from the other end.

[bdbarnett]

Proposal, no code, as asked.

The rule I would put underneath it

A wire's slot count is an electrical fact; a transducer count is an acoustic one, and today only the first one exists in this code. I2SOut converts to the wire — audiobusio.c picks want_channels = direct ? base->channel_count : 2 and everything non-direct goes through audiosample_convert_*_s16s, which is CircuitPython's rule ("Mono samples will be converted to stereo by copying value to both the left channel and the right channel"). That is right for the wire and says nothing about what is on the end of it.\n\nThe boards already know the other number. The T-Embed declares channels=(1, 2) with native_channels=1 and says so out loud: "The amp is mono into one speaker, but the wire takes two slots — so channels and native_channels differ." The information exists. It does not reach I2SOut.\n\n## Three cases, and only one of them is unanswered\n\n| content | transducers | today | proposed |\n|---|---|---|---|\n| mono | one | opens a mono slot (direct s16), or duplicates | keep: one slot, zero-copy |\n| mono | two | duplicates into both slots | keep: that is what duplication is for |\n| stereo | one | hands both slots to an amp that picks one | (L+R)/2 in software, then both slots |\n\nOnly the third row is the issue. A hard-panned guitar on the right disappears, and nothing anywhere says it will.\n\n## The part I would not guess at, and the trap in it\n\nA MAX98357A's SD pin selects left, right or (L+R)/2, by resistor. So on a board wired for (L+R)/2 the downmix already happens in the amplifier, and doing it in software as well is not a no-op — it is correct-sounding and 6 dB down, which reads as "this board is quiet" and gets fixed with a gain somewhere else.\n\nSo native_channels is not enough. It says how many transducers; what is missing is how the wire reduces to them. I would add that to AudioCapability as a fact about the board, not a policy:\n\npython\nAUDIO_OUT = AudioCapability(..., native_channels=1, mono_from="mix") # or "left", "right"\n\n\n"mix" means the hardware already averages and I2SOut must not; "left" or "right" means it does not and I2SOut must. That is a value somebody reads off a schematic once, and it is the only input the decision needs.\n\nAbsent the field, the safe default is "left" — do the downmix in software. Being wrong that way costs 6 dB on boards that average; being wrong the other way silently deletes a channel, and only one of those is audible as a fault rather than as a preference.\n\n## Where the code goes, when someone writes it\n\naudiobusio_convert(), beside the eight conversions already there. Not Python: that conversion used to run on the interpreter and cost 67 starved blocks in 2 s on the P4 playing CircuitPython's own docstring example, which is why it moved to the pump's thread. A stereo→mono row is a shift and an add per frame and belongs in the same table.\n\nAnd it is (L + R) / 2, never L + R. A sum clips on correlated material — which is most material — and the average never can. Three dB of level is the right price for a speaker.\n\n## The ES7210, which is the same question from the other end\n\nThe P4 panel declares capture as channels=(1,), native_channels=1, on I2S port 0 sharing its clocks with playback. But the codec is a four-mic ADC and es7210.py brings up two: MIC1_GAIN/MIC2_GAIN set, MIC3/MIC4 zeroed, _SDP34 = 0x00 for two-channel non-TDM. So the wire carries two slots and the capability promises one channel, and nothing in between says who reduces them.\n\nThree things to settle, and I would settle them in this order because the first two are measurements and the third is a decision:\n\n1. What does a one-channel read return today? One mic, or the two-slot stream read as mono — which would be an interleave, and an interleave read as mono is not silence and not noise, it is plausible audio at the wrong pitch. That is the failure shape that survives a listen.\n2. Which mic is slot 0, physically, on the panel.\n3. What should it return? I propose the average of the enabled mics as the default meaning of "the microphone" — it is what an app asking for one channel wants, and it is the one answer that does not silently pick a side — with an explicit way to ask for a single mic when someone is doing beamforming or a null test.\n\nAnd the mic enable should be visible in the capability rather than a register write inside the driver. Which mics are live is the board's fact, like mono_from above; today it is discoverable only by reading es7210.py's profile.\n\n## The thing that must not happen\n\nA silent single-slot pick, on either side. You get audio, it sounds plausible, and half the information is gone — which is the shape of every expensive bug written down in this workspace. Whatever is chosen, the capability should say it, so a board that does the other thing is a different declared value and not a surprise.\n\n---\n\nNothing here has been run. No code changed, and no board was touched: this is a reading of audiobusio.c, _audioif.c's slot configuration (I2S_SLOT_MODE_MONO with slot_mask = I2S_STD_SLOT_BOTH, which is worth confirming on a scope before anyone relies on what the IDF does with that pair), the two board configs and es7210.py.