Calculate actual system time of start of the first audio sample of a callback

[hcfman]

Hi all,

I'm using jackd on a system using a gps and pps to keep very accurate time with a view towards localizing sounds received from different mics. When the mics are a long way away minor time differences won't matter but I would like to try and do it with mics just located at my place.

I'm finding myself getting somewhat confused with the time handling in jackd2 and chatgpt is also not getting it right.

How can I calculate the exact system time from the very first audio sample received in the processing callback? Currently I'm just using the system time before setting everything up but I suspect that there is some discrepancies that the jackd system knows about and can fix.

I think the answer will lie somewhere in the use of jack_last_frame_time(client) at the very first call back but I'm having trouble getting it right?

Cheers,
Kim Hendrikse

[hcfman]

Actually, after further reading, I have a suspicion that it can be done by subtracting the following from the current system time. I'm not sure how I can confirm that this is correct though.

That would be

currentSystemTimeInMicroseconds - (jack_get_time() - jack_frames_to_time((jack_last_frame_time(client)))

If someone knows this and can confirm if this is correct that would be appreciated.

Kim

[kmatheussen]

What do you mean by "system time"? You mean the time returned from "gettimeofday", or do you mean the time returned by "jack_get_time()"? (I don't know if it's possible to convert between those two, unless jack uses gettimeof day underneath... (which I guess it might do))

…

On Mon, Jun 12, 2023 at 12:44 PM Kim Hendrikse ***@***.***> wrote: Actually, after further reading, I have a suspicion that it can be done by subtracting the following from the current system time. I'm not sure how I can confirm that this is correct though. That would be currentSystemTimeInMicroseconds - (jack_get_time() - jack_frames_to_time((jack_last_frame_time(client))) If someone knows this and can confirm if this is correct that would be appreciated. Kim — Reply to this email directly, view it on GitHub <#938 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIX3J6LJFVDFDXPHZ2JJGTXK3XIRANCNFSM6AAAAAAZCJUQWM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hcfman]

I can see your point. Just how fast is the callback then? I was trying to take into account any system jitter or delay in the callback. (Although... I would potentially be re-introducing any jitter by the additional calls to jack_get_time and jack_last_frame_time(), maybe more...)

Initially, I created a file with the current system time just before registering the callback. But I'm trying to triangulate from sounds recorded on separate machines just 20m apart. The system times are very accurate so it implied that some delay, perhaps caused by opening files was screwing with this estimate.

I like the simplicity of your suggestion, I'll doing both and seeing if there really is any difference or significant difference.

Likely all my error was caused by opening the file (On a raspberry pi) with an encrypted file system as well and the simple approach you suggest is more than accurate enough, maybe more accurate because it's simpler.

Thanks for the suggestion, I'll test it.

Kim

[falkTX]

it is accurate enough to generate audio continously, otherwise you get xruns. so it will be a matter of how low in buffer size you can get before you start getting xruns. alternatively increase the sample rate which results in the same (that is, more calls per second)

[hcfman]

That make's sense.

Using:

std::cout << "Diff between current system time and time of last frame " << jack_get_time() - jack_frames_to_time(client, jack_last_frame_time(client)) << std::endl;
I am seeing up to a max of around 900 microseconds difference between the jack_last_frame_time and current time.

Very small compared to the other factors that would be been happening such as opening a file with the time at the moment, but easy to take into account, so I'll just that in as well. That was max, I also saw it as low as 140 microseconds.

I was trying to account for start time estimates that were seeming to be different by more than 40ms. This looks great!

Thanks for your insights.

Kim

[hcfman]

Thanks, all sorted, I was able to account for 10m of distance that sound would travel with the corrected error. i.e. my super simple approach resulted in around 30ms of error, which is now corrected.

My final corrected bit of code is:

if (!hadFirstFrame) {
    // outputBitrate
    double buffer_time_in_microseconds = static_cast<double>(nframes) / outputBitrate * 1e6;
    jack_time_t timeToStartOfLastFrame = jack_get_time() - jack_frames_to_time(client, jack_last_frame_time(client)) + static_cast<jack_time_t>(buffer_time_in_microseconds);
    auto currentFileTime = std::chrono::system_clock::now() - std::chrono::microseconds(timeToStartOfLastFrame);

    // Update this value with the true value
    calculatedTimestamp = getTimestampFromTime(currentFileTime);

    hadFirstFrame = true;
}

[hcfman]

And experiments with the triangulation are showing that this is working very well now.

Eventually I'll put my project up on github as well. I'm using a raspberry pi with a gps to set the system time very accurately, i.e. less than 1 microsecond of error. And then I've modified a cheap USB microphone adding a quality microhone capsule and written software to store all of the audio with the accurate event times in the filenames.

From that I was able to triangulate some fireworks last night with a good degree of accuracy. Using jackd I'm able to have both recording of times suitable for use in triangulating gunshots and explosions as well as live listening with darkice. Very nice!

Kim