Re: [fluid-dev] File output with FluidSynth API

[Pedro Lopez-Cabanillas]

On Friday, March 12, 2010, Felix Krause wrote:
> On 11.03.2010, at 21:05, David Henningsson wrote:
> > If the clock_time never advances beyond zero, it definitely looks like
> > some problem with fluid_curtime (or g_get_current_time in glib).
> >
> > Could it be a rounding problem? Please try this change to
> > fluid_curtime():
> >
> > unsigned int fluid_curtime(void)
> > {
> >  GTimeVal timeval;
> >  unsigned int result;
> >
> >  g_get_current_time (&timeval);
> >  result = (unsigned int) (timeval.tv_sec * (gdouble) 1000.0 +
> > timeval.tv_usec / (gdouble) 1000.0);
> >  fprintf(stderr, "tv_sec = %d, tv_usec = %d, curtime = %d\n",
> > timeval.tv_sec, timeval.tv_usec, result);
> >  return result;
> > }
>
> Now I get:
>
> tv_sec = 1268349663, tv_usec = 980628, curtime = -1
> tv_sec = 1268349663, tv_usec = 980730, curtime = -1
> Sample_time = 0, clock_time = 0
> tv_sec = 1268349663, tv_usec = 995767, curtime = -1
> delay = 1
> tv_sec = 1268349663, tv_usec = 996886, curtime = -1
> Sample_time = 1, clock_time = 0
> tv_sec = 1268349663, tv_usec = 996922, curtime = -1
> delay = 2
> tv_sec = 1268349663, tv_usec = 998991, curtime = -1
> Sample_time = 1, clock_time = 0
> tv_sec = 1268349663, tv_usec = 999031, curtime = -1
> delay = 3
> tv_sec = 1268349664, tv_usec = 2090, curtime = -1
> Sample_time = 1, clock_time = 0
> tv_sec = 1268349664, tv_usec = 2125, curtime = -1
> delay = 4
> tv_sec = 1268349664, tv_usec = 6187, curtime = -1
> Sample_time = 1, clock_time = 0
> tv_sec = 1268349664, tv_usec = 6222, curtime = -1
> delay = 5
>
> I see the problem; fluid_curtime casts the seconds from glong to an
> unsigned int, which leads to an overflow - especially when you multiply the
> seconds with 1000. Are you on a 64bit linux? That might be the reason why
> you don't have problems with it - int has afaik 8 byte on 64bit, but only 4
> on 32bit (I'm compiling 32bit). However, the code works on Windows compiled
> as 32bit, but the time format could be another one there...

Yes, it is an overflow. I've committed a fix in revision 286. Please test.

Regards,
Pedro