[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 21:50:44 +0100
User-agent: Thunderbird (X11/20090105)

Pedro Lopez-Cabanillas skrev:
> I'm not saying that it is trivial, but I think that it is possible and would 
> be a very welcomed improvement. Issues of the current implementation that 
> must be addressed:

Thanks for reviewing the patch!

> * file output driver (fluid_aufile.c) uses another timer instance. This 
> should 
> be fixed as well, to solve ticket #15.


> * fluid_player_join() must be fixed.

My alternate implementation of that one should work (does anybody know a
sleep function for macos 9?). Actually it was the comment that misled me
into believing that fluid_player_join was only called when playing has
already stopped (which is wrong).

But fluid_player_join becomes somewhat obsolete/deprecated with the new
solution, and should be replaced with a fluid_player_get_status function
(and possibly some kind of callback when status changes).

> * MIDI rendering is delayed by one block, this needs some compensation.

Can you elaborate? I think this happens for the first block, but not the
other ones, right? (Btw, in the old/current timer solution, I guess the
delay is a bit random, which must be even worse?)

> * Ensure that the MIDI rendering ends before the last audio block has been 
> sent to the output device. It would need even some additional time if there 
> is some reverb or other effects applied.

I assume that should read as "Ensure that the MIDI rendering DOES NOT
end...". Anyway, I see this as a separate issue unrelated to my patch. I
reinstalled fluidsynth 1.0.8 from the Ubuntu archives and got a working
-i switch, and confirmed that the issue is present there as well (the
program quits too early, especially with a large audio.period-size).

// David

reply via email to

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