Re: [fluid-dev] Subversion checkins

[Josh Green]

On Tue, 2007-09-18 at 09:11 +0100, Rui Nuno Capela wrote:
> >> It seems as though, rather than dither_index being trampled on, the
> >> synth pointer might be bad.  Is the pointer value (and its
> >> initialization, etc.) thread-safe?
> >>
> >
> > I just discovered what is wrong.  Mystery is, I don't see how it would
> > work at all on any system with meters enabled in QSynth.
> >
> > Seems some of the audio driver re-working I did caused the problem.  The
> > new_fluid_audio_driver2 does not require a synth instance in order to
> > function, since the callback function is responsible for rendering the
> > audio.  Somehow I overlooked this fact and assumed that the data parameter
> > was the Synth, when in the case of QSynth its actually its own internal
> > synth class.
> >
> > I'll have to think more of how to fix this problem though, since now
> > that the 16 bit dithering is used, there are some variables in the synth
> > instance that need to be accessed even in the case of the audio callback
> > method.  Probably won't be until later this week when I can get to it.
> >
> > Thanks again for all the probing!
> >
> 
> yeah, good show. indeed new_fluid_audio_driver2() only takes a opaque
> argument that is feeded unchanged to the callback function, and in case of
> qsynth, that pointer is of a qsynthEngine instance and _not_ a
> fluid_synth_t as you (wrongly;) assumed.
> 
> after all and out of curiosity, the crash symptoms were just about data
> alignment as i have suspected in the first place ;) as the very first data
> member of qsynthEnngine class is in effect the respective fluid_synth_t*
> one. that almost explains the intermitent crash behavior: it just varies 
> how the qtractorEngine instance is being loaded in memory and that could
> actually change with the working set, compiler, linker-loader whatever.
> but sometimes it can get it right just by coincidence ;)
> 
> conclusion: it does seem that the new_fluid_audio_driver2() function
> should be considered deprecated and a new one should follow, eg.
> new_fluid_audio_driver3() which would include an additional but mandatory
> parameter in its signature as for the old forgotten fluid_synth_t*
> instance.
> 
> qsynth can try to use this new api entry whenever available at ./configure
> time.
> 
> cheers
> -- 
> rncbc aka Rui Nuno Capela
> address@hidden


Ha ha, I guess that does explain why it actually could work sometimes,
if the FluidSynth instance is at the start of the qsynthEngine.

As for the new_fluid_audio_driver2(), it is kind of an ugly hack, which
is what got me in trouble in this case, since I was trying to simplify
things.  Previously the new_fluid_audio_driver and
new_fluid_audio_driver2 were completely separate almost identical pieces
of large code.  In the interest of easing maintenance, I reduced them to
2.  I think rather then adding a new_fluid_audio_driver3, the dithering
stuff should be extended to have a dithering "instance" which does its
own internal housekeeping in regards to the current index in the
dithering buffer.  The new_fluid_audio_driver2() path could then create
its own instance and use it.

At some point it might be nice to create a fork of FluidSynth and make
those badly needed overhaul changes which very well could break some of
the API.  I think a lot of that can be done under the hood though,
without any API breakage.

Cheers!
        Josh