I’m building Ardour here with MSVC so I’m not technically using the release code (I build from the nightly code) but I also see this message with some sessions. Another common problem here is sessions hanging just after displaying the message “Finished adding tracks/busses”.
When I run the code in my debugger there’s no one place where the hang occurs but the most common places are this code in Session::post_engine_init()
PBD::Mutex::Lock lx (AudioEngine::instance()->process_lock ());
ProcessorChangeBlocker pcb (this);
std::shared_ptr<RouteList const> r = routes.reader ();
for (auto const& i : *r) {
i->configure_processors (0); // <--- HANGS HERE
}
or this code in Session::hookup_io()
try {
std::shared_ptr<Auditioner> a (new Auditioner (*this));
if (a->init()) { // <--- HANGS HERE
throw failed_constructor ();
}
auditioner = a;
}
Maybe the devs might be able to see something that’s common to them?
@John_E , that code is unrelated to the case at hand. The error the user has happens much earlier.
“Failed to register audio/midi ports” is from the back-end. Search for the error message and find PortRegistrationError in portaudio_backend.cc
We’ve seen issues here if the device name includes umlauts or accents. @tnaugle is investigating a related issue where driver detection on Windows can hang.
–
As for the issue you posted, I suspect this is due to your custom build.
Hi Robin, I had an urgent appointment yesterday so I had to give you the shortform version. What’s happening here is that some sessions contain a section looking like this (which works):-
<ControlProtocols>
<Protocol name="PreSonus FaderPort" active="no"/>
<Protocol name="Generic MIDI" active="no"/>
<Protocol name="Mackie" feedback="no" bank="0" ipmidi-base="21928" device-profile="User" device-name="Mackie Control Universal Pro" active="yes">
<Configurations>
<Configuration name="Mackie Control Universal Pro">
<Surfaces>
<Surface name="Mackie Control Universal Pro">
<Port>
<Input>
<Port name="mackie control in" direction="input"/>
</Input>
<Output>
<Port name="mackie control out" direction="output"/>
</Output>
</Port>
</Surface>
</Surfaces>
</Configuration>
</Configurations>
</Protocol>
<Protocol name="Open Sound Control (OSC)" active="no"/>
</ControlProtocols>
whereas in the ones that won’t load, it looks like this:-
I’m not saying that that’s necessarily causing the problem but it’s the only obvious difference I can see. And I’m not really sure why they’d be different anyway??
Good suggestion. Due to a different problem I’ve had to revert the code for a while and build from some previous code (so the problem’s gone away for the moment). But thanks anyway and I’ll keep that in mind in case it returns.
