std::bad_alloc with Ardour and play-loop #1
Comments
|
On 02/11/2016 08:55 AM, Thorsten Wilms wrote: hmm. looks like a specific ardour condition, probably due to strict yes synthv1::alloc_sfxs() is called to reallocate/extend the fx-send does it crash/aborts with std::bad_alloc exception only when looping? seeyarncbc aka. Rui Nuno Capela |
|
I haven't seen std::bad_alloc in any other case, lately. Loop marker positions do play a role, it seems the crash only happens if the end marker comes before bar 129 (in this particular session). rgareus just told me: ardour can change the process period size any time (split cycle, automation, analysis). It can be any value between 1 and 8192 and every cycle can be different (though usually it's mainly the same). Plugins can request a specific period size via http://lv2plug.in/ns/ext/buf-size/ (in which case ardour won't load them). |
|
On 02/11/2016 01:51 PM, Thorsten Wilms wrote:
are you willing to test the thing, meaning synthv1-lv2 et al. as i willing to play some tests from synthv1 git pull's every now soon and then? i'd really appreciate (my ardour4.6+ builds are crashing on me at every cheersrncbc aka. Rui Nuno Capela |
|
today's git head master has some tentative mitigation please test && tellrncbc aka. Rui Nuno Capela |
that's simply awful. synthv1-lv2 asks the host for LV2_BUF_SIZE__maxBlockLength option on instantiation. why oh why doesn't ardour give it the 8K buffer-size value for x sake??? |
|
nominalBlockLength is what you want to use in the plugin then. the plugin should prefer nominalBlockLength if available, otherwise use max. |
|
Still throws an instance of 'std::bad_alloc' with synthv1 current git. |
Ardour does tell plugins 8192 for LV2_BUF_SIZE__maxBlockLength and 1 for LV2_BUF_SIZE__minBlockLength as instantiation parameters. Works just fine. Why oh why does your plugin not understand it :) |
because it's failing on parsing the LV2_Options_Option array? oops. my oh my mistake... ok. please try this again: thanksrncbc aka. Rui Nuno Capela |
|
Still 'std::bad_alloc'. |
|
On 02/11/2016 08:55 PM, Thorsten Wilms wrote:
and is it on the same spot? at synthv1::alloc_sfxs()? that can only mean that ardour is probably going over its own reported would you be kind and edit the line tia.rncbc aka. Rui Nuno Capela |
|
On 2016-02-11 17:43, Filipe Coelho wrote:
all of the buffer-size options are being acquainted for: byeerncbc aka. Rui Nuno Capela |
|
yes, I misread the code there, sorry. |
|
Still at Wondering if I made a mistake, on a second attempt, I went through |
|
On 2016-02-12 12:32, Thorsten Wilms wrote:
i then suspect that the plugin (.so) that are being loaded onto your please search all under /usr/lib_/lv2/, /usr/local/lib_/lv2/ and seeyarncbc aka. Rui Nuno Capela |
|
I removed the sole instance of a synthv1.lv2 bundle, tripple-checked the change in the code, did a fresh build ... still the same result. Backtrace looks like the first. |
|
On 02/12/2016 08:06 PM, Thorsten Wilms wrote:
does alloc_sfx() call follows right on synthv1_lv2::run() ? if on i've tested on a fresh build on today's ardour git head and actually i think i'm loosing on you here... anyway, it was already strange why as said synthv1::process(nframes) only calls synthv1::alloc_sfxs() on kinda puzzled now :/ seeyarncbc aka. Rui Nuno Capela |
|
why not adding a test print in there? my guess would be that a miscalculation somewhere is leading to negative values. |
|
IRC is nice, but if anyone needs to make sense of this later on: |
|
synthv1_lv2.cpp, added |
|
With the |
|
With Same with line 170 back to original |
(n_samples = 64 but Ardour sends midi-buffer with an event at 960) some guesses as to why: - split cycle for looping (nominal: 1024, cycle split:64) - plugin uses _session.transport_frame() directly :( (not latency compensated offset or looped position) - "offset" is not taken into account for midi buffers - tempo/metric change (metric iterator is wrong after loop)
After no response on IRC, I tried to report this on Sourceforge, but creating a ticket there failed with 405, method not allowed.
Segfault of Ardour (current git) with
terminate called after throwing an instance of 'std::bad_alloc', when the end of the loop range is reached during play-loop and a LV2 instance of synthv1 is enabled. No crash if the plugin is disabled.The Ardour/play-loop/synthv1 combination used to work, so either a recent Ardour update triggered the issue, or there must be another ingredient. I now have an Ardour session that will crash everytime if one just starts play-loop after loading. No such issue with other synth plugins.
Backtrace:
The text was updated successfully, but these errors were encountered: