koobas.hobune.stream
Delay with Microphone.Start
Hi!
I have a problem regarding recording audio and playing it back insync with other audio. I am trying stuff for a few days already but i can't figure it out :(
I want to make an app where the user can record his own audio over a playing audioclip (looping). So when he is done, both tracks should be played simultaneously and in sync.
So what i am doing is the following:
Audio class (pseudocode kinda)
Update(){
if(AudioSource.timesamples < previousTimesample)
if(isRecording){
StopRecording()
} else {
StartRecording()
}
}
previousTimesample = AudioSource.timesamples
}
-------------------------------
This should start (and stop) a new recording when the current track is starting from its beginning. On the PC this is not a problem and it's pretty much insync, but on mobile devices there is a little difference (which i expected). What i expected was that in the beginning of the recorded audio a few milliseconds would miss. But to my surprise, instead of less there is more! Below is an example of the waveforms. The first waveform is the looping audio, the second one is the recorded audio. The first peak in this example (with the black line in front of it) should be insync, but as you can see it is not! :(
Summary
With the code, i expect that the peak of the second waveform should be a little bit sooner then the first waveform. But it's the opposite. Does someone know why this happens?
Also, i can image it is not all very clear. Please ask for clarification if you don't get it! :)
Does the problem happen even the first time the track starts? Unity's $$anonymous$$icrophone class is a little weird, as it doesn't tell you when it's ready to record. You call $$anonymous$$icrophone.Start(...) but it doesn't start recording right away, and the problem is magnified on mobile platforms. We must actively poll it until the recording position is correct, using while($$anonymous$$icrophone.GetPosition(micName) <= 0); after calling Start. This stops your application until the recording position becomes positive. I realize this is horrible, but it's needed and, as far as I know, Unity does not provide a better way. If you're not already doing this, try it. If it solves your problem I'll convert this comment into an answer. If not, I currently have no other ideas :)
This is the behaviour i also expect. But what happens is that it starts recording to soon :o In theory (code wise) i expect it to start a little bit after my Update function calls StartRecording. In that case the peak of the second waveform should be sooner then the first one. But as you can see in the waveform the peak is after the first one.
As a workaround i am now going to try to start recording sooner and then just cut the piece out of it that i want.
I just ran into exactly the same problem. i guess, it is not about when the recording starts but about latency. the hardware needs some time to encode the recorded voice, so even though the recording is already running, the data comes in a bit later, that is why you seem to have "more" recorded data. in fact, it is just delayed. but i have actually no idea how to find out, what the amount of the latency is. did you find a good solution?
@fruitservice: Check my answer on my own post below ;) I have tried weeks to find the latency without any good results. The solution i posted below worked pretty good for me.
In case anyone will bump into this problem. I'm going to make a 'calibrate microphone' function (let my phone make some loud noise). It will save the time between expected audio-input and actual audio-input.
Demo here: https://play.google.com/store/apps/details?id=com.zuidsoft.loopstation2
Can you provide some insight how to $$anonymous$$imize the delay?
Hi @renezuidhof,
I've been struggling for a couple of days with a similar thing. Can you provide some insight on how you did it?
Thanks
James
I play an audioclip of 3 seconds with a clicking sound every second. At the time the audioclip starts playing i also start recording with the microphone. Now i analyze the recorded audio to find the peaks of the clicking sounds. Because the first peak should ideally be after exactly one second you can check the actual time of the first peak. So the difference between the expected peak and the actual peak is your delay.
Ahhh interesting.
Thanks for the answer.
