fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] fluid~ crashes


From: Josh Green
Subject: Re: [fluid-dev] fluid~ crashes
Date: Sat, 03 Jan 2004 01:20:28 -0800

On Thu, 2003-12-25 at 10:50, Frank Barknecht wrote:
> Hallo,
> 
> I'm having a problem with my fluid~ external [1] for Pd/Max crashing
> Pd. This is with the current CVS version of fluid~ and Pd 0.37.  I'm
> using the libfluidsynth package from Debian, which is at version
> 1.0.3. 
> 
> Creating the object and loading soundfonts works fine, but as soon as
> audio is turned on, a patch with the fluid~ object crashes Pd. 
> 
> I found out, that Pd crashes at the calls to fluid_synth_write_float
> in the dsp function of fluid~, which looks like this: 
> 
> void fluid::m_signal(int n, float *const *in, float *const *out)
> {
>       
>       if (synth == NULL) return;
>       
>       float *left  = out[0];
>       float *right = out[1];
>       // This crashes:
>       fluid_synth_write_float(synth, n, left, 0, 1, right, 0, 1); 
>       
> }  // end m_signal
> 
> 
> If I comment out fluid_synth_write_float Pd does not crash. I can write to
> the left or right arrays as well (like setting left[1] = 0.4 by hand),
> so somehow the error has to be inside the fluid function. Can someone
> reproduce this and maybe has an idea about a reason? 
> 
> [1] Source code for fluid~ is at pure-data.sourceforge.net in the CVS
> here: 
> http://cvs.sourceforge.net/viewcvs.py/pure-data/externals/footils/fluid/fluid/
> 
> ciao


It seems you haven't received a reply to this problem, so I'll see if I
can help any. I haven't really used Pd that much or even tried the
FluidSynth binding for it, and I won't likely get around to tracking it
any time soon, so I don't think I can be of much help, but..
If you want to try and track it down yourself here are some tips:

Compile FluidSynth with debugging support enabled (./configure
--enable-debug I believe, --help to get a list of options).
Fire up Pd with GDB 'gdb pd'.
Tell GDB to not trap thread related signal SIG32:
(gdb) handle SIG32 nostop noprint

Run Pd:
(gdb) r

Do what you would normally do to get it to crash. After it crashes get a
back trace:

(gdb) bt

That should give you a list of all the function calls leading up to the
crash. Post that to this list, then I might be able to help more.
Cheers.
        Josh Green





reply via email to

[Prev in Thread] Current Thread [Next in Thread]