When exporting long sessions with freewheeling, pulseaudio
may meanwhile suspend the corked audio device. The "FAIL_ON_SUSPEND"
option then prevents ardour to uncork it after export, and the
audio-backend is halted.
*PluginInfo::load() eventually calls `plugin->set_info()`
which depends on a valid PluginPtr. The method needs to return
early if `plugin` is unset or null.
Route::realtime_handle_transport_stopped() does have insufficient
information (PostTransportLocate), so "flush" is called from
Route::non_realtime_transport_stop in the butler thread.
However plugin de/activate() must not be called concurrently with
processing. e.g. https://lv2plug.in/ns/lv2core explicitly states:
"Hosts MUST guarantee that: An Instantiation function for an instance
is never called concurrently with any other function for that instance."
This would later trigger an assert() in MidiRingBuffer<T>::read
when reading the status-byte, and cause undefined behavior down
in optimized builds.
It is unsure if this can happen, but it may explain
https://marcan.st/paste/LHDXNQ9x.txt
The file linked from the bug report has a meter-change
in the middle of a bar. Ardour maps this back to the previous
bar, which already has a meter-change. Session load fails with
"Multiple meter definitions found at 473"
The tempo-map of the file ends like this:
```
Meter 11/32 @227040 (beat 473)
Meter 4 / 4 @227680 (beat 483.666667)
```
This potentially breaks various assumptions (e.g. no resampling,
fixed buffersize) when the stream is moved to a different device.
Then again it's pulseaudio, which is unsuitable for pro-audio to
begin with.
This uses an atomic counter and spins only on the writer side, which
preserves realtime behavior on the reader side. The spinning yields (by
using the same Boost function from Boost spinlocks) to be
scheduler-friendly.
Fixing this bug also lets us be able to confidently drop garbage early
in the writer if appropriate, so do that and avoid keeping dead wood if
possible.
This reverts commit f95439a502:
"add spinlock to RCU manager to protect concurrent reader() and update() calls"
This can happen if the buffers have different sizes.
This fixes crashes that bisected to 7c37a18b7, but it is not the root
cause; it just happened to make things worse.
