ActionScript: playing sound from the microphone on the speakers (via the buffer) with constant delay

Question

I am looking for an example of a code that samples a microphone signal and plays it on speakers. I need a solution that has a resonantly constant delay on different platforms (PC, Android, iphone). A delay of about 1-2 s is suitable for me, and I don’t if it changes every time the application starts.

I tried to use the SampleDataEvent.SAMPLE_DATA event in the Sound and Microphpne class. One event puts the data in the buffer, others will read the data. But it seems impossible to provide a constant delay, either the delay grows constantly, or it gets lower to the point where I have less than 2048 samples to muffle the sound and stop the sound by generating SampleDataEvent.SAMPLE_DATA events.

I do not process every incoming frame, so using setLoopBack (true) is not an option.

ps This is more of a problem on Android devices than on PC. Although, when I start resizing the application, the window for PC latency also starts to grow.

Please, help.

Answer 1

Unfortunately, this will not be possible ... at least not directly.

Some audio devices will use a different clock between recording and playback. This will be especially true for cell phones, where what works on a microphone can be great equipment than the audio output for headphones.

Basically, if you record at 44.1 kHz and play at 44.1 kHz, but this watch is not synchronized, you can record at 44.099 kHz and play at 44.01 kHz. Over time, this drift will mean that you will not have enough data in the buffer to send to the output.

Another complication (and most likely your problem) is that your recording and playback frequencies may vary. If you record with a microphone at 11 kHz and play at 48 kHz, you will notice that 11 does not even fit into 48. The software is often used to re-sample the recording. Sometimes this is done with a good algorithm, which is guaranteed to give you the desired result. In other cases, that 11 kHz will be brought up to 44 kHz and is considered "close enough."

In short, you cannot rely on synchronizing recording and playback devices, and you will need to synchronize yourself. There are many algorithms to handle this. The easiest way is to add a sample here and there, which averages the sample before and after it. If you do this with just a few samples, it will not be heard. Depending on the type of drift problem you have, this may be enough.