View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009696 | ardour | bugs | public | 2024-04-23 10:01 | 2024-04-26 13:25 |
| Reporter | johne53 | Assigned To | x42 | ||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Microsoft | OS | Windows | OS Version | 10 |
| Product Version | Mixbus 9.x | ||||
| Summary | 0009696: Mixbus10 crashes when enabling / disabling Atmos | ||||
| Description | Firstly, this is affecting the new MB ver10, rather than MB ver9. Also, be sure to back up your test session as the following can cause data loss... 1) Load any session which already has Immersive Panning enabled 2) Disable it for a few seconds then try to re-enable it. On my system (Windows 10) this invariably causes Mixbus to disappear from my screen 3) My About box shows me revision 10.0 and running from a Command Line gives this output when the crash occurs:- (Mixbus:11312): glibmm-ERROR **: 08:27:00.031: unhandled exception (type std::exception) in signal handler: what: Required Vapor Processor not found. | ||||
| Additional Information | A Mixbus user called Dingo tried (on an Intel Mac system). He couldn't reproduce the problem although enabling or disabling Immersive Panning apparently takes a long time on MacOS. So I tried leaving a much longer time between disabling and re-enabling but it doesn't help on Windows. So I ran Mixbus in a debugger this morning and the exception gets thrown at this line in LV2PluginInfo::load() :- try { [...] plugin.reset(new LV2Plugin(session.engine(), session, lp, session.sample_rate())); // <--- EXCEPTION THROWN HERE !!!! [...] } catch (failed_constructor& err) { return PluginPtr((Plugin*)0); } So to me, it looks like the crash should be affecting all platforms. Or maybe (on Windows) that particular plugin can only be reset (or instantiated?) once for some reason??? | ||||
| Tags | No tags attached. | ||||
|
|
what: Required Vapor Processor not found. Is this the official binary, or your MSVC build? |
|
|
I cannot reproduce this on Win7 with Mixbus 10.0.11 (official binary from harrison). |
|
|
Hi Robin - it's the official binary (which reports itself as ver 10.0) Ordinarily I'd suggest that I update to 10.0.11 but I tried an MSVC build from the latest code and that also fails... I've done some more tests this morning and realised that it doesn't affect all sessions. For example, I create a new session using the 'Empty' template, then I save (and close) the session after first selecting Immersive Panning and assigning a Master Output. If I then follow the instructions above, that one doesn't crash. But if I do exactly the same thing except using the 'Jazz-Backing-Band' template, that one does exhibit the crash. And I've managed to narrow it down a bit further... the duff code is in Lilv at this line within the function 'lilv_plugin_instantiate()':- result->lv2_handle = ld->instantiate( ld, sample_rate, bundle_path, (features) ? features : local_features); // <--- HERE !!!! I can't find the declaration for 'features' but it seems to contain 2 x fields called 'URI' and 'data'. After disabling Immersive Panning and then re-enabling, 'data' ends up having a value of 0xcdcdcdcdcdcdcdcd (which MSVC uses to indicate that something's uninitialized). So my guess would be that disabling Immersive Panning caused 'data' to get deleted somewhere. That's probably about as close as I can get... |
|
|
Is Dolby ATMOS only available for 48kHz ? I am reading this and seeing the sample rate variable in the code where the exception occurs. If I remember correctly, I may have had a crash on the V10 demo as well, but it was related to having a sample rate of 44.1kHz. It is likely my audio driver on my Win10 forced it to 44.1kHz, even though MB defaults to 48kHz now. The old preferences were also copied over, that were previously set to 44.1kHz. Immersive ATMOS worked after that. That was my experience with the V10 Demo. |
|
|
Possibly worth a mention is that Cubase 13 requires a minimum block size of 512 to use Dolby ATMOS. |
|
|
Ardour/Mixbus automation works differently, so the buffersize constraint does not apply. However Atmos does require a sample-rate pf 48k or 96kHz as specified by Dolby. |
|
|
Thanks @Schmitty2005. I checked my sessions here and they're all 48Khz. In quite a few places we save this as a floating point number (48000.00000) so I guess it's possible that it'll screw things up if it gets reduced somewhere to 47999.99999 but I didn't see any evidence of that. Robin - I dunno if you got a chance to try the Jazz-Backing-Band session at your end but after some further tests this morning I've concluded the following... 1) Either this'll come down to some bug in Lilv - or 2) There's some aspect of a-vapor.dll which prevents it from being instantiated a second time - or 3) When we disable Immersive Panning, we leave the a-vapor plugin in some state whereby it can't then be re-instantiated |
|
|
2,3 is a possibility. The plugin can only be instantiated once, but here it is properly cleaned up. I still cannot reproduce this even with the recipe you provided using the Jazz-Backing-Band. Now it could be that the change mixbus+10.0-7-g780c7c0ca6 makes a difference. I don't have a 10.0.0 binary around to check that. I have also checked with -fsanitize=address to make sure that there are no leaks or memory corruption. LV2 feature array is passed along correctly as well. So this remains a mystery. I am not sure what else I can test. Does the crash happen during `instantiate` or does `instantiate` simply return NULL? Also note that the session sample-rate is saved as 64 bit integer (samplecnt_t) not a floating point value. While some plugin APIs use double, that is not true for the rate inside Ardour. Where do you see it serialized as float? |
|
|
Yes you're right - I've just realised the double is in Lilv (in that call to 'ld->instantiate()' that I referred to earlier...) And you're also right about the return value. The call to' ld->instantiate()' returns correctly when called prior to disabling Immersive Panning but returns zero when called afterwards. Whereabouts is the 'instantiate()' function? MSVC won't let me access the code so I assume it must be in the plugin? And if so, maybe the plugin is also expecting double? |
|
|
Sorry, I meant ld->instantiate() returns NULL |
|
|
> I meant ld->instantiate() returns NULL OK. That can happen when there already is an instance of the plugin. Can you check if lilv_instance_free() is called? Perhaps there is some shared_ptr<> reference that keeps the plugin around under some circumstances. I don't yet see it but I'll keep looking. |
|
|
I think you're onto something here Robin. 'lilv_instance_free()' gets called in various other circumstances but not when I disable Immersive Panning. |
|
|
I have an idea.. Here the Windows machine only has 2 cores. So there's no process graph (which may hold a reference). Can you check that changing the process graph (make a new connection, or add some track) allows to re-add immersive pan: 1. Load session with immersive pan 2. disable immersive panning 3. add a track 4. re-enable immersive panning |
|
|
Yes that works the first time I try it but if I keep the session open and then run steps 2 and 4 again (but without step 3 in between) it'll usually crash again. Likewise, if I close the session then re-open it, the original issue is still present - but I guess that's probably what you're expecting? |
|
|
Fixed in Mixbus 10.0-14-g8bbbf49694 |
|
|
Hi Robin - that's fixed the crash I reported but with a couple of weird caveats... Firstly, when I try to close Mixbus, Lilv will now sometimes assert at this code in 'lilv_state_new_from_instance()' :- if (iface) { LV2_State_Status st = iface->save( instance->lv2_handle, store_callback, state, flags, features); if (st) { LILV_ERRORF("Error saving plugin state: %s\n", state_strerror(st)); free(state->props.props); state->props.props = NULL; state->props.n = 0; } else { qsort(state->props.props, state->props.n, sizeof(Property), property_cmp); } } I haven't narrowed it down yet as it only happens very occasionally so I'll report back if it becomes reproducible. Another thing that's confusing me is during the original call I reported earlier:- result->lv2_handle = ld->instantiate( ld, sample_rate, bundle_path, (features) ? features : local_features); As we now know, that call was often failing - but when it did succeed, I vaguely remember the a-vapor plugin allocating an address to 'features->data' but that's not happening any more. I guess I might be misremembering so I'm just flagging it up in case it's significant. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-04-23 10:01 | johne53 | New Issue | |
| 2024-04-24 02:50 | x42 | Note Added: 0028672 | |
| 2024-04-24 02:53 | x42 | Note Added: 0028673 | |
| 2024-04-24 08:34 | johne53 | Note Added: 0028674 | |
| 2024-04-24 23:27 | Schmitty2005 | Note Added: 0028677 | |
| 2024-04-25 01:48 | Schmitty2005 | Note Added: 0028680 | |
| 2024-04-25 02:45 | x42 | Note Added: 0028681 | |
| 2024-04-25 06:53 | johne53 | Note Added: 0028682 | |
| 2024-04-25 12:29 | x42 | Note Added: 0028683 | |
| 2024-04-25 13:21 | johne53 | Note Added: 0028684 | |
| 2024-04-25 13:23 | johne53 | Note Added: 0028685 | |
| 2024-04-25 13:55 | x42 | Note Added: 0028686 | |
| 2024-04-25 14:14 | johne53 | Note Added: 0028687 | |
| 2024-04-25 15:53 | x42 | Note Added: 0028688 | |
| 2024-04-25 16:59 | johne53 | Note Added: 0028689 | |
| 2024-04-26 03:14 | x42 | Assigned To | => x42 |
| 2024-04-26 03:14 | x42 | Status | new => resolved |
| 2024-04-26 03:14 | x42 | Resolution | open => fixed |
| 2024-04-26 03:14 | x42 | Note Added: 0028693 | |
| 2024-04-26 13:25 | johne53 | Note Added: 0028694 |
