0
0

Hello folks,

I’m working on an application to calculate the exact time when a sound signal is recorded by a microphone.
To synchronize my clock with the position, where the soundcard is actually recording, I use the getRecordPosition() function.

Unfortunately this function is very inaccurate. Several pollings over 1 minute give me a random error of several hundrets of samples (ca. 10 ms) from the position where it should be. With that it’s the main source of error in my algorithm.

Do you have any idea why this could be?

And do you know about a workaround? I should really "ask" the soundcard, at which position it actually is (otherwise I get a huge systematical error).

  • You must to post comments
0
0

You didnt specify what platform and output mode you are talking about.
Also i’m not sure what you’re needing this accuracy for. getRecordPosition is usually updated in chunks, because the driver does that. 10ms is not ‘very innacurate’ it sounds pretty close to me, that is about 441 samples at 44khz.
The purpose of the function is usually so that you can tell where to copy data from using the record sample buffer when copying it into your destination buffer.

  • You must to post comments
0
0

Hello,

I should have specified that. My system is windows XP SP2 with non-ASIO soundcard. I’m not setting the output mode manually, so according to the manual FMOD defaults to WINMM.

I need the recording position for 2 reasons.

1) To determine the position up to where I can lock the sound and process the recorded audio

2) To exactly find out, when a recorded audio signal happened. For that I have to know where FMOD is exactly recording. Just start the recording and calculate the expected number of samples passed would lead to a huge statical error. In that case, 10 ms is a large error.

Thank you anyway for your response.

  • You must to post comments
0
0

Recently I began to cope with that issue of getRecordPosition() again. I would need it very precise, in the order of 0,1 ms.

I figured out, that getRecordPos() doesn’t count samples but chunks (like you said). Every ~20 ms it increases by [i:1zfacbqt]f[/i:1zfacbqt] * 441, where [i:1zfacbqt]f[/i:1zfacbqt] = 1..4 with an average of 2
(That results in 44100 samples / sec).

Obviously some sort of chunk buffer. If [i:1zfacbqt]f[/i:1zfacbqt] were predictable, there wouldn’t be a problem, I could interpolate. Unfortunately [i:1zfacbqt]f[/i:1zfacbqt] won’t follow any observable rule and jumps wildly around like 1,4,2,3,1,4….

The averaging I do results in a certain error which I think is unnecessary.
setDSPBuffer(512, 8) improves the thing, as [i:1zfacbqt]f[/i:1zfacbqt] only changes between 1 und 2, instead of up to 4. But it doesn’t help finally.

Do you know a way to get the counter always increase by a fixed amount?

Regards, Johannes

System: AthlonXP, WinXP SP2, FMOD 4.24.07

  • You must to post comments
0
0

even if you had 1 sample increments, the operating system wouldnt be able to do it. It has to be done in chunks because an update thread has to sleep periodically to service the output, it can’t sleep in microseconds, it can only sleep in milliseconds, and somewhat innacurately, so the timer is usually around 10ms to update each frame.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.