Was being called without initializing PA. PA should probably be initialized in
ctor but PA backend also needs to support hot-plugging devices at some point so
this will do for now
Connect to the backend_combo changed signal after setting state as calling
backend_combo.set_active_text() in set_state was triggering backend_changed(),
which would then see the driver_combo had not been set and set it to the
incorrect value.
The value/name of the backend needs to be restored first then we can populate
the driver combo and set the correct active entry from the saved state. After
which backend_changed() will populate the device combo's etc so they can then
be set to the correct active values from the saved state.
This is not a real fix; just a stop-gap for the worst offender.
iostream on OSX is not thread safe.
Sadly no crash report so far managed to catch the 2nd thread in action.
looks like the GUI thread is preempted, 2nd thread succeeds, and the
crash occurs later).
see also https://discussions.apple.com/thread/3479591
crash in
s << c->internal_to_user (c->get_value ());
ardour-4.1.335(5000,0x7fff777f5300) malloc: *** error for object 0x7fe2f3e06170: pointer being freed was not allocated
1 libsystem_c.dylib abort + 129
2 libsystem_malloc.dylib free + 428
3 libsystem_c.dylib __numeric_load_locale + 544
4 libsystem_c.dylib loadlocale + 216
5 libstdc++.6.dylib std::__convert_from_v(int* const&, char*, int, char const*, ...) + 193
6 libstdc++.6.dylib std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_float<double>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, char, double) const + 193
7 libstdc++.6.dylib std::ostream& std::ostream::_M_insert<double>(double) + 221
8 ardour-4.1.335 ProcessorEntry::Control::set_tooltip() + 854 (processor_box.cc:578)
9 ardour-4.1.335 ProcessorEntry::Control::control_changed() + 446 (processor_box.cc:637)
10 ibpbd.dylib PBD::StandardTimer::on_elapsed()
