Re: [fluid-dev] Subversion checkins

[Josh Green]

Hello Rui and list,

I'm caught up in some work deadline stuff again, but will be getting
back to FluidSynth in the next week or so.  At that point I will be
ready to give the new_fluid_audio_driver2() audio interception stuff
some respect ;)  There was of course no intention to break it.

        Cheers!
        Josh

P.S. A Trac ticket has been opened for this issue:
http://fluidsynth.resonance.org/trac/ticket/5

Please don't feel shy to create your own bugs, although you will need to
register for an account.  At this point I don't mind filing them myself
though.



On Fri, 2007-09-07 at 18:40 +0100, Rui Nuno Capela wrote:
> David Hilvert wrote:
> > On Wed, 5 Sep 2007 14:38:36 +0100 (WEST)
> > "Rui Nuno Capela" <address@hidden> wrote:
> > 
> >> two questions, no solution, but might help pointing out the offender:
> >>
> >> 1) is fluidsynth built for debug (-g)?
> > 
> > Building with -g gives the following slightly more detailed result:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1318044784 (LWP 31842)]
> > 0xb7eb2f4b in fluid_synth_dither_s16 (synth=0x8174860, len=940, 
> > lin=0x89eec68, rin=0x89efb20, 
> >     lout=0x89f09d8, loff=0, lincr=2, rout=0x89f09d8, roff=1, rincr=2) at 
> > fluid_synth.c:1828
> > 1828        left_sample = roundi (lin[i] * 32766.0f + rand_table[0][di]);
> > (gdb) where
> > #0  0xb7eb2f4b in fluid_synth_dither_s16 (synth=0x8174860, len=940, 
> > lin=0x89eec68, rin=0x89efb20, 
> >     lout=0x89f09d8, loff=0, lincr=2, rout=0x89f09d8, roff=1, rincr=2) at 
> > fluid_synth.c:1828
> > #1  0xb7e90652 in fluid_alsa_audio_run_s16 (d=0x8111dc0) at fluid_alsa.c:558
> > #2  0xb7e6e2d3 in start_thread () from /lib/libpthread.so.0
> > #3  0xb73cf2fe in clone () from /lib/libc.so.6
> > 
> >> 2) are qsynth's output meters enabled?
> > 
> > The problem seems to be reproducible when output meters are enabled, and 
> > does
> > not seem to occur when the meters are disabled.
> 
> that's what my suspicion was.
> 
> qsynth is forking the audio path with new_fluid_audio_driver2() when the
> output meters are enabled.
> 
> maybe this route in fluidsynth is not very well optimized in regard to
> data alignment for instance or else something even worse and hideous...
> 
> on macosx it was known to crash almost exactly as this, isn't that so
> Ebrahim? but iirc latest reports say the situation seems to have been
> cleared ;)
> 
> until someone gives some respect to this seldom used fluidsynth code
> path, you better turn off those qsynth output meters, it's only
> eye-candy anyway :(
> 
> bye now