tmr: add tmr_continue()

[vanrein]

to allow jiffie-accurate interval timer continuation
usually called from within the handler function

RTP timing can normally be derived best from an audio source.
This does not work when delivering content from a file, or when
delivering generated content.

The tmr_continue() call is a slight modification of tmr_start()
and can be used to continue a timer after an internal, which is
added to the current timeout, avoiding stacking timing errors.

[vanrein]

Notes:

1. The FreeBSD check that failed does not look like I caused it.
2. For fresh software I would have included the bool syncnow flag in tmr_start_dbg() but I chose to keep the ABI in tact and so use an extra function call to share code.

[sreimers]

I wonder if tmr_continue() helps. timers are not very accurate, since the main event loop runs multiple tasks, so its normal that a tmr event can be late. If you need accurate timing, its better to use a separate thread with sys_msleep(), especially if blocking filesystem access is involved.

[vanrein]

I think you are talking about jitter, and I agree that this is not addressed by this patch. The common resolution for transmission+network jitter is a buffer on the receiving end.

But to send sound file contents or generated audio, there is no tool in libre. What is needed, is a way to have a regular interval, so as to maintain an average speed. If this is done with repeated calls to tmr_start() then jitter piles up without hope for correction. The proposed tmr_continue() still introduces jitter, but it does not pile up, so jitter correction at the receiver is possible.

I also got this working with setitimer(ITIMER_REAL) and signal() handling SIGALRM, but it feels awkward to mix concurrency models. Moreover, the behaviour I had was unpredictably wrong, with restarts of the transmitted data, possibly due to subtle memory/cache problems. With tmr_continue() I am not seeing the file restarts that I noticed with a signal handler, and that screwed up the sound.

I think that tmr_continue() adds value, but also agree that it is subtle.

[sreimers]

Suggested change

	tmr_startcont_dbg (tmr, delay, true, th, arg, file, line);
	tmr_startcont_dbg(tmr, delay, true, th, arg, file, line);

[vanrein]

FYI, I considered another formulation in tmr_start() but that would make timer continuation the default and that might break applications that assume that they may reuse a timer after a period of non-use.

    if (tmr->jfs == 0)
        tmr->jfs = tmr_jiffies ();
    tmr->jfs += period;

This would recognise the all-zero situation after tmr_init().

Having no detailed documentation the (very readable) code serves as an API, so I thought it better to not break with existing behaviour. A lighter variant, but possibly even less predictable, would have been

    uint64_t jfs_now = tmr_jiffies ();
    if (tmr->jfs + period < now)
        tmr->jfs = now;
    tmr->jfs += period;

The benefits of the form in this pull request are unaltered and more consistent behaviour and fewer calls to tmr_jiffies().