View Issue Details

IDProjectCategoryView StatusLast Update
0008576ardourbugspublic2021-04-16 14:15
Reporterunfa Assigned Tox42  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
PlatformRyzen 7OSManjaroOS VersionKDE
Product Version6.5 
Summary0008576: "GUI POOL OUT OF MEMORY" crash when using Alt+7 on a group of audio clips
DescriptionI've been changing region gain on a bunch of audio clips in a project, while suddenly when I ha eve hit Alt+7 about 40th time in this session I saw this error dialog:

> CRITICAL: GUI POOL OUT OF MEMORY - RECOMPILE WITH LARGER SIZE!!

I'm running an official 6.5 build of Ardour.

What I've noticed in the session before was very heavy GUI slowdown - I've heard that Surge 1.8 is causing these slowdowns, maybe this is a terminal result of that?
Tagscrash

Relationships

related to 0008626 closedx42 GUI pool out of memory when inserting silence. 

Activities

unfa

2021-02-15 14:14

reporter  

Screenshot_20210215_150557.png (107,156 bytes)   
Screenshot_20210215_150557.png (107,156 bytes)   

unfa

2021-02-15 15:01

reporter   ~0025522

I've unwillingly reproduced this in the same way:

1. Strip Silence off of a minute-long audio clip
2. Move these, move some to a second audio track and rearrange them on two audio tracks
3. Select groups of the m in the Grab mode and reduce region gain with Alt+7 repeatedly.
4. Get the error message

unfa

2021-02-15 15:08

reporter   ~0025523

So far I've tried pressing Alt+7 repeatedly much slower to avoid tripping this wire. Successfully.

x42

2021-03-22 01:32

administrator   ~0025635

Significantly improved the situation in 6.6.159.

It's still possible to trigger this by when changing regions on many different tracks and press+hold Alt+6/7 with key-repeat.
Previously every region caused 2 events to be queued (up to 4096) which are then slowly processed. Now it's only 2 per track.

There's ongoing work to improve this further.

x42

2021-03-22 01:58

administrator   ~0025636

to elaborate: when the gain changes, the track's playback buffer is re-read from disk with the gain-change applied.

Region:read() data from disk is the "slow" part. with repeated changes many disk-reads were queued.
This is no further mitigated by merging consolidating requests. in 6.6.160

anonymous

2021-04-16 14:15

viewer   ~0025708

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2021-02-15 14:14 unfa New Issue
2021-02-15 14:14 unfa Tag Attached: crash
2021-02-15 14:14 unfa File Added: Screenshot_20210215_150557.png
2021-02-15 15:01 unfa Note Added: 0025522
2021-02-15 15:08 unfa Note Added: 0025523
2021-03-21 21:49 x42 Relationship added related to 0008626
2021-03-22 01:32 x42 Note Added: 0025635
2021-03-22 01:58 x42 Note Added: 0025636
2021-03-22 01:58 x42 Assigned To => x42
2021-03-22 01:58 x42 Status new => resolved
2021-03-22 01:58 x42 Resolution open => fixed
2021-04-16 14:15 anonymous Note Added: 0025708
2021-04-16 14:15 anonymous Status resolved => closed