13
0

Non-ideal but functional fix for problems when adding processors which increase the required number of scratch buffers.

git-svn-id: svn://localhost/ardour2/branches/3.0@6105 d708f5d6-7413-0410-9779-e7cbd77b26cf
This commit is contained in:
Carl Hetherington 2009-11-17 01:42:55 +00:00
parent 6c21a54509
commit 16e5bd5ce7

View File

@ -1376,7 +1376,6 @@ Route::configure_processors_unlocked (ProcessorStreams* err)
_in_configure_processors = true;
// Check each processor in order to see if we can configure as requested
ChanCount in = _input->n_ports ();
ChanCount out;
@ -1398,6 +1397,15 @@ Route::configure_processors_unlocked (ProcessorStreams* err)
}
}
/* Take the process lock so that if we add a processor which increases the required
number of scratch buffers, we create those scratch buffers before the process
thread has a chance to ask for them.
XXX: in an ideal world we'd perhaps use some RCU magic to avoid having to take
the lock here.
*/
Glib::Mutex::Lock pl (_session.engine().process_lock ());
// We can, so configure everything
list< pair<ChanCount,ChanCount> >::iterator c = configuration.begin();
for (ProcessorList::iterator p = _processors.begin(); p != _processors.end(); ++p, ++c) {
@ -1407,6 +1415,12 @@ Route::configure_processors_unlocked (ProcessorStreams* err)
out = c->second;
}
/* make sure we have sufficient scratch buffers to cope with the new processor
configuration */
_session.ensure_buffers (n_process_buffers ());
_session.ensure_buffers (n_process_buffers ());
_in_configure_processors = false;
return 0;
}
@ -2741,7 +2755,8 @@ Route::set_block_size (nframes_t nframes)
for (ProcessorList::iterator i = _processors.begin(); i != _processors.end(); ++i) {
(*i)->set_block_size (nframes);
}
_session.ensure_buffers(processor_max_streams);
_session.ensure_buffers (n_process_buffers ());
}
void