[Top][All Lists]
[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
- Re: [fluid-dev] fluid~ crashes,
Josh Green <=
- Re: [fluid-dev] fluid~ crashes, Frank Barknecht, 2004/01/03
- Re: [fluid-dev] fluid~ crashes, Frank Barknecht, 2004/01/03
- Re: [fluid-dev] fluid~ crashes, Josh Green, 2004/01/03
- Re: [fluid-dev] fluid~ crashes, Frank Barknecht, 2004/01/03
- Re: [fluid-dev] fluid~ crashes, Eric Van Buggenhaut, 2004/01/03
- Re: [fluid-dev] fluid~ crashes, Frank Barknecht, 2004/01/04
- Re: [PD-dev] Re: [fluid-dev] fluid~ crashes, Larry Troxler, 2004/01/04
- Re: [PD-dev] Re: [fluid-dev] fluid~ crashes, Josh Green, 2004/01/04
- Re: [fluid-dev] fluid~ crashes, Josh Green, 2004/01/04
- Re: [fluid-dev] fluid~ crashes, Eric Van Buggenhaut, 2004/01/04