On Wed, Jun 02, 2004 at 11:37:53AM +0100, Carl Hetherington wrote:
vstserver's, I believe. There's the message about the audio thread
taking 10 seconds and being killed; the audio disappears during those
ten seconds.
Seems like you are out of luck. Last thing to try is to start
the vstserver with the --nonrealtime option to see if it can
be the watchdog that is screwing things up. But I doubt it.
I've managed to improve things a bit; I've not had an audio thread killed
since I did one of these three things:
1. Disabled the plugin GUI (commenting out the lines as you suggested)
2. Changed vsti/jackclient.c to queue MIDI data and send it to the plugin
during the audio thread (like jack_fst does).
3. Run at a buffer size of >= 64 samples.
I'm not sure how many of these are important, but one of them is ;-)
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 ?
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language