Re: [fluid-dev] callbacks

[David Henningsson]

On 2010-11-08 19:32, Element Green wrote:
> On Mon, Nov 8, 2010 at 12:37 AM, David Henningsson<address@hidden>  wrote:
> > On 2010-11-07 21:20, Jari Suominen wrote:
> > > Hi there!
> > >
> > > I'm developing simple sampler program on top of fluidsynth and am
> > > wondering that is there any way to receive callbacks when voices
> > > finish/loop etc.
> >
> > Depending on what you're planning to do, you might want to help out with
> > SWAMI or QSynth instead of building yet another FluidSynth frontend.
> >
> > > Like if I have one sample that is x seconds long
> > > assigned to some key on my soundfont and after that sample has played
> > > through.
> > >
> > > Reason for doing this is that I would like to build a custom controller
> > > that would have visual feedback of what is happening inside fluidsynth
> > > engine.
> > >
> > > Any ideas how to achieve this. Or did I just miss something in the API?
> >
> > There is no way (in the API) to get such callbacks. It is possible you might
> > be able to poll for whether a voice has disappeared or not using
> > fluid_synth_get_voicelist. Note that usage of this function from a
> > thread-safe perspective might need some additional thought to make sure the
> > voices don't disappear in parallel with you trying to read them...
> >
> > // David
>
> This is also some API that I am interested in, for Swami.  I'll work
> on it at some point, if no one gets to it before me.  I think there
> may be a callback or something (IIRC) which allows one to know when a
> sample is no longer used by FluidSynth, which would help with garbage
> sample collection and some limited status.  I'm not certain as to the
> thread safety aspect of it currently though.
>
> My current FluidSynth API wishlist:
> - 24 bit and/or floating point sample data support

...and the easiest way forward, would that be to depend libInstPatch? 
How much does libInstPatch currently do and what would need to be 
implemented in FluidSynth?

> - Voice playback pointer querying

The 1.1.2 engine currently makes it hard to read anything that is 
changeable by rendering. I'm not saying it's impossible though, we could 
add atomic stuff that updates the playback pointer (and perhaps other 
stuff as well). I would like to do that configurable though in order to 
get maximum performance from use cases that does not need this 
functionality.

The other option would be that you do this yourself from the rendering 
thread, but then you would have to hook into the audio driver and you'll 
have to be careful in order to avoid underruns.

Callbacks leaves us the question as of from what thread(s) the callback 
should be called. We have two options, either directly from the hard 
real-time side, or transferred back to the soft real-time side. Now 
remember that the engine does not own any threads on either side, so 
you'll get the callback inside a call into the engine (which in turn 
could be done by yourself or by a midi/shell/audio driver).

> - Current voice count

Already possible via fluid_synth_get_voicelist.

> - Ensure sample garbage collection can occur in a thread safe fashion

Hmm, I haven't looked into this. Looking at the code now, there seem to 
be calls for fluid_sample_decr_ref from both threads. It would be fairly 
easy to move all calls to the soft real-time side, we should probably do 
that. As for thread safety, you would then be guaranteed to only get one 
notify callback at a time.

// David