Addition: I've just implemented seeking and MID length measuring (as in time). The seeking and the measurement is perfectly working, so now i understand even less why the timing is off. Is usleep() this unreliable? Edit: It is the same with nanosleep().

The time signature information is used if you are converting to or from an amount of measures.

If you are just converting an amount of ticks into an amount of seconds then you do not need to use the time signautre information in the calculation.

A is a delta time duration in ticks
B is the tempo event value in microseconds per quarter note
C is the header resolution value in ticks per quarter note
D is the duration in microseconds

A × B / C = D


  A ticks        quarter note     B microseconds     D microseconds
            ×  ──────────────  ×  ──────────────  =
               C ticks              quarter note

I found some documentation describing the usleep and nanosleep functions of the Standard C library. They each say they will suspend execution of the calling thread for at least the time specified. In other words, the suspended duration may be more that what was requested.

I don't know what alternative to use instead, but I think the concept to search for is a timer (?).

Thank you, that is the problem. I wrote this small routine and the difference is much less now:

void prusleep(uint32_t us)
{
	struct timespec tp0, tp1;

	clock_gettime(CLOCK_MONOTONIC_RAW, &tp0);
	tp0.tv_nsec += (us % 1000000) * 1000;
	if (tp0.tv_nsec > 1000000000)
	{
		tp0.tv_nsec -= 1000000000;
		++tp0.tv_sec;
	}
	tp0.tv_sec += us / 1000000;
	do
	{
		usleep(10); // 6% slower if present, 2.25% slower if not
		clock_gettime(CLOCK_MONOTONIC_RAW, &tp1);
	}
	while ((tp1.tv_sec < tp0.tv_sec) || ((tp1.tv_sec == tp0.tv_sec) && (tp1.tv_nsec < tp0.tv_nsec)));
}

But the problem is still present. Even if i take out that usleep() from the waiting cycle, it is still 2.25% slower than it should (this time i measured it) and then it creates a massive CPU load to no surprise.

Originally i did the timing by accumulating each track's delta and then subtract lowest delta from all accumulators and wait that time. For this caused the thread becoming difficultly interruptible because some long deltas, i reorganized it to wait one tick in each round. But this caused low wait times which in turn caused usleep() and nanosleep() waiting too much as you've correctly predicted. I now went back to the original approach for the moment and now even usleep() is only 2.25% slower, but on the other hand even this precise timer is still 2% slower. (1.9% with no internal usleep.)

I am sure i am doing something wrong, but i have no idea what and how could i make the timer more precise. (But logic says, if i check the monotonic clock from a sleepless cycle, that cannot be topped.)