Re: [fluid-dev] Timing revisited

[David Henningsson]

Josh Green skrev:
> On Sat, 2009-04-25 at 21:30 +0200, David Henningsson wrote:
>> About the buffer, first I think it should be an additional component
>> between the "producer" and the synth. We don't want to introduce the
>> overhead of thread safety when we don't need it, e g when using fast
>> midi-file rendering or in some embedded cases.
>>
>> Second, I was thinking perhaps this buffer is the sequencer? A sequencer
>> is really just a buffer with the additional feature of delaying an event
>> (which can come in handy if we want a really stable midi file player in
>> combination with low latency).
> Indeed that does make sense that the circular buffer is the sequencer.
> It starts getting more complex when events are removed in non FIFO
> order.  Rather then re-invent something that is already out there,
> perhaps we should do some research on how other projects have tackled
> this.

I've had a look at the sequencer and I'm optimistic that it can be the
buffer we need without too much adjustments. It's even threadsafe
already (with mutexes). It sometimes does some job from the callback
(which then will be called from the audio thread with the sample
timers), but it seems to have an acceptable upper bound for that job, as
long as you watch out for:

- Inserting a lot of midi events at the same time (will scale linearly
against the number of midi events inserted)

- Inserting midi events more than 65536 ticks away from current time
(will walk list of all other events > 65536 ticks away)

- Having many ticks per fluidbuffer frame (as long as you don't have
more than 256 ticks per frame this shouldn't be a very big problem for
the upper bound, I think)

- Using the FLUID_EVT_ENTRY_REMOVE feature

I think it can be optimized as well if it turns out to be slow, but I
don't think that is a problem. (Btw, one thing could be by turning
queue1 into a ring buffer just as queue0, by remembering a "prevCellNb"
for queue1 as well.)

>>> It would be nice to start using glib for some basic things, like data
>>> types, hash tables, etc.  Cleaning up main could also be refreshing :)
>>> Perhaps I'll get inspired to tackle some of that.  
>> That would be nice. I have not used glib but it seems to come in handy.
>> For Linux I assume depending on glib would not be a problem, but will
>> there be problems on other ports?
> glib is available for just about any Unix system (Linux, BSDs, Mac OS X,
> etc), Windows and apparently OS/2.  It does add an additional dependency
> of course, which would need to be provided, either packaged with
> FluidSynth or otherwise.  For the sake of cleaner and more portable
> code, I think it is worth it.
> 
> I'm thinking of dropping the Mac OS 9 support in FluidSynth.  If anyone
> objects, you better speak up!

We will also drop Win9x support if we depend on latest glib. Not a big
deal either IMO.

I haven't heard anyone object to using glib, so will you add the
necessary changes to the build system for depending on glib so we can
try it out?

// David