David Hilvert wrote: > On Wed, 5 Sep 2007 14:38:36 +0100 (WEST) > "Rui Nuno Capela" <[EMAIL PROTECTED]> 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 -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
