Column Switch - Stuttering

[Oaktown]

Can you share the artwork as well?

[Oaktown]

There seems to be a lot of layer to slice assignments in the advance output (20+) so I am curious to know what happens if you disable the advanced output and just go fullscreen.

[nightjar84]

There seems to be a lot of layer to slice assignments in the advance output (20+) so I am curious to know what happens if you disable the advanced output and just go fullscreen.

Yes it does (though less frequent and not with the sample footage of resolume!)

I really think this is the point where the Team of Resolum should step in.

[Oaktown]

Yes it does (though less frequent and not with the sample footage of resolume!)

Can you share your footage?

I really think this is the point where the Team of Resolum should step in.

Have you contacted them directly via feedback in the preference menu? Make sure you include your log file(s).

[Zoltán]

I really think this is the point where the Team of Resolum should step in.

Have you contacted them directly via feedback in the preference menu? Make sure you include your log file(s).

Menno already replied here with a few questions: viewtopic.php?f=12&t=16853#p69553

Resolume definitely doesn't send your SSD to sleep, that's sure.

I can see a similar short freeze on my mabcbook pro, and a very very short freeze on my machine with the 1080Ti (12 layers), looks almost like 1 or 2 frames.

When you switch columns of 6-9 layers playing to another with transition time, you have 12-18 clips decoding and playing at the same time during the transition.
The new clip data has to arrive from the drive to the GPU in this short amount of time,
Playing 10 layers of 1080p DXV clips I see up to 250MBytes/sec sustained read speed from my SSD, Double that during a transition.

You could get some headroom by using Normal quality DXV clips.

I'm not sure if this can be improved by us, Menno could give us better information on this.

I'm also not sure why the 30 seconds matters so much for you in the difference in behaviors, and why others don't see this appearing as you do.
Could be an OS Buffering thing.

[nightjar84]

Thanks for your answer.

Tried all different flavors and resolutions of DVX 3...no changes!

I see the point when talking about 18 clips...though it also happens with 3 / 6 clips. Eventhough 18 clips are 250 MB/s an SSD should easily handle that, let alone an SSD raid / NVME as in the MB

On my macbook: I mostly get the stuttering / frame freezes when I switch to a column with multiple layers (startiung from only three!)

on my PC with a GTX 1080: I only get the stuttering if a column had been playing for a while (not exactly 30 seconds...it seems to vary) - when I switch the column after 5 seconds or so - it is smooth as butter --> this fact highly points toward a bug / performance issue of arena!

You're right. What really suprises me is that nobody has complained about this before...maybe people with more complex mapping projects (eventhough 9 simultaneous videos don't seem that crazy) don't use arena...?

Cheers,
Janis

[Menno]

I think there's several issues at play here. During a trigger there's quite a bit of work we have to do. First of all we have to read the frames from disk. Then we have to unpack it, upload it to the gpu and decompress it. Then when all of that is done we still need to render the frame. A large part of the work we have to do is us having to acquire hardware resources that we need for playback. Arena has always been a tool that runs in an environment where multiple applications run simultaneously. For this reason Arena is built to not be greedy on hardware resources and free them up when we don't need them anymore. The result of this is that you can safely run multiple applications on a single machine, but this comes at the cost of us having to spend time acquiring those resources at a later point in time.

We've already got a ticket to make Arena more greedy on hardware resources. The idea is that we wont free up resources back to the OS when we think we might need them anywhere in the future. Additionally we might want to pre-allocate some of these resources when we think you might need them soon (eg when you load a deck, you're probably going to play something from that deck) This will make Arena more unfriendly to the environment it's running in, so we still need to figure out how far we want to go with this.

The issue you're seeing that after x amount of time a trigger becomes a problem could have two reasons. Part of this problem could be that Arena frees up some of it's unused resources after they havn't been used for 10, and some more after 51 seconds. The other part of the problem is likely the OS's file cache. Whenever any application reads a file, the os puts the contents of the file into unused memory. Then when that file is read again the os gives the application the contents in memory rather than the contents from disk. The os is doing this because disk io (especially non ssd disks) is much slower than memory io.
What could be happening on your machine is that the os doesn't have enough free memory to store files for both columns into memory. It then discards the contents from the non playing files and replaces it by contents of the playing files. If you then trigger those files again the contents have to be read from disk rather than memory. Even with a 2GB/s ssd reading a HD frame could take a millisecond, which is 1/17th of the budget we've got each frame. If you're triggering a column that will add a few milliseconds of time on that frame, which i think you can imagine quickly pushes us over the time budget for that frame. (causing a framedrop)
There are ways for applications to steer this file caching behavior but we havn't been doing this up to this point because when done incorrectly it can easily crash Arena or worse (reduce system stability). I'll bring it up for discussion here so that we can see if maybe it's time to start using this anyway.

[JFC3d]

How did you fix this issue?