Re: [fluid-dev] Subversion checkins

[Rui Nuno Capela]

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
-- 
rncbc aka Rui Nuno Capela
address@hidden