[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Patch for bad MIDI timing (with large buffer sizes)

From: David Henningsson
Subject: Re: [fluid-dev] Patch for bad MIDI timing (with large buffer sizes)
Date: Sat, 14 Mar 2009 11:58:28 +0100
User-agent: Thunderbird (X11/20090105)

Pedro Lopez-Cabanillas wrote:
> Your former patch implements a "slave" timer, using the frame counter from 
> the 
> synthesizer itself as a time source. I think it may be a right way to go.
> About the implementation, I would prefer to do it as an option, and not a 
> replacement of the former timer. And there is a timer usage in the file 
> output driver (fluid_aufile.c) that should be revised, or removed when used 
> with your system, to render MIDI files faster than wall clock.

When you say option, do you mean as an #ifdef, or as an
fluid_settings_xxx option?

I'm not sure why we should keep the old behaviour though. The only
reason I can currently think of, would be if the sample rate is wrong
somehow, which I guess could only happen if the sound card actually
plays back samples in another sample rate than requested to - but if
that is the case, the result would be instruments slightly out of tune,
so it's bad anyway.

> There is a pending 1.0.9 release, so IMHO this is not the right moment to 
> include your patch into trunk. Also, it would be better if you can provide 
> an "svn diff" patch, instead.

Okay. If I revise my patch to include an option to keep the old
behaviour, and to rewrite parts of fluid_aufile to fix ticket #15, and
provide the result as an svn diff patch, and all this would be done in a
few days, would you (and the other developers) think that would make
1.0.9 wait for that patch or would you rather release 1.0.9 as quick as

>> Was the "-i" broken in 1.0.8? The 1.0.8 version I've got here seems to
>> quit immediately if the -i option is used.
> It works as expected here. Please provide all the command line arguments, 
> files and other details of your tests.

It's possible I've messed up installed versions here. I will try to
compile the svn trunk version to see if the problem is reproducible there.

// David

reply via email to

[Prev in Thread] Current Thread [Next in Thread]