CODEWITHSUNDEEP
actionscript-3flashaudioactionscriptsignal-processing
Sebastian Dusza
Sebastian Dusza

Reputation: 2528

Actionscript: Playing sound from microphone on speakers (through buffer) with constant delay

I'm looking for an example of code that samples signal from microphone and plays it on speakers. I need a solution that has a resonably constant delay on different platforms (PC, android, iphone). Delay around 1-2 s is ok for me, and I don't mind if it varies everytime the application starts.

I tried using SampleDataEvent.SAMPLE_DATA event on Sound and Microphpne classess. One event would put data into buffer the other would read data. But it seems impossible to provide constant delay, either the delay grows constantly or it gets lower to the point where I have less than 2048 samples to put out and Sound class stops generating SampleDataEvent.SAMPLE_DATA events.

I wan't to process each incoming frame so using setLoopBack(true) is not an option.

ps This is more a problem on Android devices than on PC. Althought when I start to resize application window on PC delay starts to grow also.

Please help.

Upvotes: 4

Views: 718

Answers (1)

Brad
Brad

Reputation: 163602

Unfortunately, this won't be possible... at least not directly.

Some sound devices will use a different clock between recording and playback. This will be especially true for cell phones where what is running the microphone may very well be different hardware than the headphone audio output.

Basically, if you record at 44.1kHz and play back at 44.1kHz, but those clocks are not in sync, you may be recording at 44.099kHz and play back at 44.101kHz. Over time, this drift will mean that you won't have enough data in the buffer to send to the output.

Another complication (and more than likely your problem) is that your record and playback sample rates may be different. If you record from the microphone at 11kHz and playback at 48kHz, you will note that 11 doesn't evenly fit into 48. Software is often used to up-sample the recording. Sometimes this is done with a nice algorithm which is guaranteed to give you the necessary output. Other times, that 11kHz will get pushed to 44kHz and is deemed "close enough".

In short, you cannot rely on recording and playback devices being in sync, and will need to synchronize yourself. There are many algorithms out there for handling this. The easiest method is to add a sample here and there that averages the sample before and after it. If you do this with just a few samples, it will be inaudible. Depending on the kind of drift problem you are having, this may be sufficient.

Upvotes: 3

Related Questions