How should MakeCode and MicroPython change the microphone gain

[microbit-carlos]

Should they be using uBit.audio.processor->setGain()? What do those values represent? Should it be done somehow else?

We are trying to offer to the users a way to change the "microphone sensitivity".

[JohnVidler]

After discussions with the folks at Makecode, we've decided to include a new call in the processor which presents gain on a sensible floating multiplier format. ie. 1.0 == no gain, 2.0 == 2x gain, etc.

This will be added in for the next tag.

[microbit-carlos]

@JohnVidler will this also affect things like levelSPL, or just the recording and playback?

[microbit-carlos]

@JohnVidler is it right to say that this is a "no fix" because the StreamNormalizer::setGain() (uBit.audio.processor->setGain()) already does this with a gain of 1.0 being "no change"?

The odd thing is that we need to reduce the gain to get decent sound quality without a lot of distortion: https://github.com/microsoft/pxt-microbit/blob/c61a905bd191830f60e2b581dd3c73633e84d36f/libs/audio-recording/recording.ts#L169-L180

    export function setMicGain(gain: AudioLevels): void {
        switch (gain) {
            case AudioLevels.Low:
                setMicrophoneGain(0.079);
                break;
            case AudioLevels.Medium:
                setMicrophoneGain(0.2);
                break;
            case AudioLevels.High:
                setMicrophoneGain(1.0);
                break;
        }
    }

[JohnVidler]

This is a bit of an odd one, as the values we chose 'way back when' for the mic gain were picked to maximise the range of values we see; the intent was to get as close to full-swing data under 'normal' use.

However, you're right, all the examples downstream seem to dial the gain down by default quite a bit, as can be seen in the MakeCode example code above.

As I'll be looking at the missing data blocks from the ADC shortly, I'll also re-examine our defaults for gain internally, and see if we can get a more sensible range, although any changes now will require updated in downstream languages (MakeCode/Python) to account for the changes in CODAL.

Getting back to the question at hand; yes this is a 'no fix' as downstream languages should really create their own StreamNormalizer and use the gain controls on that to locally alter the gain for their own purposes, unless they really want a global gain dial, in which case the default Normalizer can be used, but know that it may have effects on the sensitivity of other components, as there may be other things hanging off the splitter for the system one.