<br><br><div class="gmail_quote">On Sun, Mar 1, 2009 at 3:49 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="Ih2E3d">On Sun, Mar 1, 2009 at 2:07 PM, Martin Profittlich <span dir="ltr"><<a href="mailto:martin@profittlich.com" target="_blank">martin@profittlich.com</a>></span> wrote:<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
I think the solution would be to prevent the JACK thread from accessing<br>
the plugin during freeze altogether, but I'm not sure what the proper<br>
way to do this is. Any suggestions?</blockquote></div><div><br>it should be possible by setting Session::processing_prohibited, see for example libs/ardour/session.cc:4106 </div></div></blockquote><div><br>Hmm, the real work of freeze takes place in Session::write_one_audio_track(), which is already doing this. <br>
<br>The backtrace should reveal more ...<br> <br></div></div><br>