Re: [fluid-dev] Subversion checkins

[Rui Nuno Capela]

On Tue, September 18, 2007 16:30, Josh Green wrote:
> On Tue, 2007-09-18 at 09:11 +0100, Rui Nuno Capela wrote:
>> 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.
>

yeah, but new_fluid_audio_driver2() is actually broken or defficient
probably since its inception ;)

otoh qsynth might just be the only one using it :)

cheers
-- 
rncbc aka Rui Nuno Capela
address@hidden