i've made the audiobackend call the session directly so that only one object (ARDOUR::Session) has a need for the JACK types
and only one .cc file (session_jack.cc) needs jack.h. having ARDOUR::AudioEngine act as an intermediary would be cleaner
conceptually but would end up causing two different ARDOUR objects to have jack types in their own API.
if sub-frames are used, frames are rounded up for the later half of
a sub-frame. e.g. @48KSPS, 25fps, 100 subframes per frame
audio-samples >=1910 already yield 00:00:00:01
bug:
- add midi track
- add additional midi port
- remove additional midi port
- press play
-> crash
because..
ARDOUR::MidiTrack::roll's route_buffer still has 2 midi-channels. This is
because processor_max_streams was not updated (no plugins added/removed)
fill_buffers_with_input() eventually asserts when trying to get the 2nd
(nonexistant) midi port via ARDOUR::PortSet::nth_midi_port() in
ARDOUR::PortSet::port().
fixes loading a session with tracks that have more input-ports
than output-ports.
the problem:
input -ports are added first, when added, IO::ensure_port() emits
IOChange::ConfigurationChanged which in turn triggers the route to
allocate corresponding output ports.
Due to this callback the output-ports were created before the actual
output-port-configuration and plugin-configuration from the
session-state was parsed and set.
do not allow port-removal if the port would be re-added immediately
after that again because the main-delivery actually needs it.
As a side effect this prevents this crash:
* create a stereo-track, then remove one output
-> unhandled exception "AudioEngine::PortRegistrationFailure&"
The problem:
- the port is removed from the RCU ports list,
but Port::drop() (which calls jack_port_unregister) is only called
from the Port's destructor at some later time.
(because a reference to the port still exists elsewhere)
- the jack-port is not yet removed.
- meanwhile Delivery::configure_io comes along and notices that
there are more audio-buffers than ports and tries to re-register the port.
- but the port still exists in jack, so it fails and throws an exception
...which is not handled.
* forward midi-data around plugins that have no MIDI-out
* allow to insert plugins with no MIDI-input at a point with one MIDI-channel
This works because excess ports (both plugin and route) remain
unconnected and use scratch-buffers.
Tested with LV2, LXVST and LADSPA.
(AU plugins with variable in/out retain the old behavior, no bypass)
fixes http://tracker.ardour.org/view.php?id=5630
