2 Jun
2004
2 Jun
'04
2:54 p.m.
On Wed, Jun 02, 2004 at 02:57:43PM +0100, Carl Hetherington wrote:
the reply said "you have them"
but i get the same output from my libc.
this looks like a tls problem.
i would try to change the libc version.
try to get a libc without tls or a new gcc.
but i am not sure.
i had similar thread and wine related problems with libfst.
we override the threading implementation wine uses in libfst.
so it could be that we dont support this tls stuff properly.
i have different things to do right now, so i wont dig in this threading
code.
can you trace the location where the segfault is happening ? is it in
fst_init ? or later ?
[snip]
That's what I thought. At some stage I'll submit my patch to vsti which
makes this change there as well.
It seems that the VST spec is not very specific about which functions can
be called in what threads.
right... such things are discussed on vst-plugins list.... :(
Do you
have any thoughts on the MIDI sending change? Perhaps you know the
reason for jack_fst doing it differently?
some plugins are very picky about what function is called in which
thread.
we also expect the plugins to behave as bad as possible.
which in this case is have one list of events without locking, or with
locking and audio thread blocking.
so the most sensible thing is insert the midi stuff in the audiothread. galan does the same thing.
does jack_fst work ?
Unfortunately not. I'm still getting the same segfault which I reported
to this list on Thu, 27 May 2004 under the thread "jack_fst segfault".
If there's anything I can do to help solve the jack_fst problems, please
let me know.
Thanks
Carl
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language