[Ardour-Dev] Time wraparound because of nframes_t = uint32_t

[Hans Baier]

>> What kind of bugs are you referring to?
>>
> Hi Hans - They're mostly to do with high timecode values.  I work in an area
> of the industry known as "post production" where pretty much every project
> starts at a high timecode value (typically, 10 hours).  Here are two bugs
> that I first reported on Mantis in June 07 and Sept 07 respectively:-
>
> http://tracker.ardour.org/view.php?id=2282
>
> http://tracker.ardour.org/view.php?id=2384
>
> One of the bugs has been acknowledged but never fixed.  The other hasn't
> even been acknowledged - even though I've made several offers to fix it
> myself.

This is a fundamental problem in Ardour: the type of
time measurement (nframes_t is an uint32_t), ie. it is limited
to 32Bit values. Its maximal value is 2^32-1. Divide this by the
samplerate and by 60*60 and you get wraparound at 12,427567378 hours
which matches with your observation.

You could try to change libs/ardour/types.h:60
from
	typedef uint32_t                    nframes_t;
to
	typedef uint64_t                    nframes_t;

and then fix all upcoming compile errors.
(I am referring to the source of 3.0 here).