Show AudioEffectCapture by use of a shader showing the captured waveform in stereo

[goatchurchprime]

Microphone data is normally read using AudioEffectCapture rather than AudioEffectRecord, so we should adapt this demo project to use it. And a good way to show that something is happening is to plot the waveform using a shader.

This shows it in stereo because a lot of computers have two microphones.

It's also useful to measure the sample rate of the microphone according to the data stream it is generating.

[Calinou]

Use snake_case for all variable names, e.g. audio_sample_size.

[Calinou]

Remove commented out lines.

[Calinou]

Tested locally on 4.4.stable (Linux), it works as expected. I've tested mic_record, not mic_input which fails with a script error on startup:

Parser Error: Static function "start_microphone()" not found in base "GDScriptNativeClass".

Is there a reason we have two demo projects now? They basically look identical at a surface, and we should try to keep the existing name for compatibility.

One issue I noticed in mic_record (but also mic_input) that the root node in the project (MicRecord) is rotated by 0.1 degrees, so the whole UI looks very slightly rotated. This is noticeable on the visualizer because it's not 100% straight.

[goatchurchprime]

Many apologies for the extra mic_input project. It's WIP for testing out PR#105244.

This is a proposal for a new function Input.get_microphone_buffer(int p_frames) which is needed because the current method of:

AudioOutput <- AudioBus [ AudioCaptureEffect ] <- AudioStreamPlayer [ AudioStreamMicrophone ]

is unreliable because it locks two real-time serial buffers at two ends of the same chain, and any systematic drift between them eventually blows past any buffer.

[goatchurchprime]

I've rolled back the changes to the audio/mic_record demo in the hope that the AudioStreamMicrophone->AudioEffectRecord method of accessing the microphone will eventually become obsolete if PR#105244 gets accepted. The demo of the new interface with is in audio/mic_input.

I've also added in some shader code to visualize the sum of the left and right stereo microphones when progressively shifted in time. This is best tested with a pure tone of 400Hz, making a consistent 8 cycles across the 20ms sample window. To make this easy I've added in a drop-down option to generate these tones.

If you deploy this project to an Android phone so you can play the tone out loud while moving it to different positions about your stereo microphones, you get this kind of movie where you can see the waveforms shifting in amplitude and phase.

screencast.mp4