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

[Pedro Lopez-Cabanillas]

Bernat Arlandis i Mañó wrote:
> Pedro Lopez-Cabanillas escrigué:
> >> perhaps the below implementation is better than the one in
> >> the patch posted earlier, but still bad, as it quits before all samples
> >> have reached the soundcard.
> >
> > 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.
>
> I would like to know the real problem being solved by this patch. Since
> this patch just synchronizes the synth and midi threads, I think it
> might be a concurrency problem with the synth and midi threads, I think
> we talked there might be some missing required locks.
>
> On the negative side, for big buffer sizes, the midi resolution timer
> will be lower than it should because the midi resolution will be the
> same as the audio latency.

The patch is not yet ready. Right. But it is an obvious way to solve two very 
important goals:
* MIDI rendering faster than wall clock (ticket #15)
* Predictable output. Rendering a MIDI sequence several times, to produce  
exactly the same frame values each time.

I don't agree with you about the locks. In the current implementation, when 
you render a MIDI file there are two main threads involved:
* A thread from the audio driver, sending output frames to the audio device. 
* The timer thread that triggers MIDI events in the Synthesizer.
Using David' solution, we are eliminating the second thread. There is only one  
now, so there shouldn't be any locking problems between threads.

About the time resolution, it depends only on FLUID_BUFSIZE (=64 frames), 
because the timer is triggered in fluid_synth_one_block(). For a sample rate 
= 44100 Hz the resolution is .68 milliseconds, which is enough for me.

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:
* 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.
* MIDI rendering is delayed by one block, this needs some compensation.
* 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.

Regards,
Pedro