OpenGL render bugs with JACK #65584

Operating system: Kubuntu 18.10, 4.18.0-20-generic #21-Ubuntu SMP Mon May 6 18:45:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Graphics card: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)
Broken: 2.80, 8fa65ed31b June 05, 23:41:04

start 2.80 with fresh config directory
open default cube scene
change audio system to JACK in preferences
in properties, change render "Output" settings to disable the "overwrite" option
in the timeline, under the "Playback" drop down, enable AV Sync
skip to a frame in the middle of the timeline (e.g. 105)
in the viewport, in View menu, choose "Viewport Render Animation"

Bug 1: observe that it delays for a while before beginning (maybe not a bug, but seemed pretty long)
Bug 2: an error pops up saying "skipping existing frame /tmp/0105"; this error occasionally appears again for subsequent frames, but usually not
Bug 3: rendering is very slow (1-2 fps, and my /tmp is a ram disk; this is true regardless of JACK/no-JACK, AV Sync or No Sync, etc)
Bug 4: (maybe just a UI paper cut?) without changing the start/end of the animation range, there appears to be no way to start an OpenGL render from a given frame unless "AV Sync" and JACK are both used?
Bug 5: (not sure if bug?) enabling/disabling AV Sync, or switching to/from JACK, often causes play cursor to change frames

Added subscriber: @clepsydrae

Added subscribers: @neXyon, @mano-wii

I don't see that JACK option on my end.
@neXyon, Audio seems to be your area.

Added subscriber: @Sergey

After spending some time playing around with this I can make the following observations:

With the overwrite option disabled, it only renders the first time. As soon as the files exist nothing happens and I get a "blank", i.e. gray grid window. I guess this is expected since files exist and blender was disallowed to overwrite them, so why should it render something? Both rendering and in the second case non-rendering start immediately, so I can't reproduce bug 1. Do you have the JACK server running before you do that? Does it only happen the first time? It might be that starting jack the first time you run this takes a while.
I also didn't encounter bug 2, neither during the first nor subsequent runs. If that bug (still?) exists it sounds like it starts rendering at the current frame, then goes back to 1 and incrementally goes from there, encountering the already rendered frame again.
Rendering being slow may be a bug, but I have no idea how fast it should be? Also that's independent even of any audio settings, so not really my area.
Regarding bug 4, I'm not sure what you mean. I tried to not touch the start/end of the animation range and start the rendering with JACK and "No Sync" and it works just fine, so I also can't reproduce this one.
Finally, the last bug 5 is not a bug but expected behaviour. When JACK + AV Sync is used, blender synchronizes via JACK transport which has its own timing. When you thus switch both these options on the cursor position synchronizes with JACK's and that's what you're observing.

May I also ask, what is your reason to use JACK?

In summary: I can't reproduce 1, 2 and 4. Bug 5 is not a bug and bug 3, if it is one is not related to audio, so I'm putting this report up for grabs. Maybe some of the stuff is related to recent changes in the dependency graph and its working with the audio system, so @Sergey might be the person to ask here.

Not sure why any of the observed issues will be related on the audio + dependency graph changes.

@clepsydrae, does any of the issues you're reported happen when you set audio system to None/Null?
What if you switch Eevee to Cycles and change number of samples/bounces to 1? Will it affect render performance?

It is also very confusing to have 5 different bugs reported in a single report. Those doesn't seem to belong to the same area, and handling such reports is tricky. It's usually a good idea to report separate issues separately.

Changed status from 'Open' to: 'Archived'

I came to respond to all the questions, and I find that I am unable to reproduce most of these issues now, either with the version I was on at the time or the current version. I have no explanation. Sorry for the confusion. I'll post again if I can. (Oddly, rendering is also faster now, perhaps 3-5 fps, and unaffected by JACK.)

I will split the reports out next time; I didn't know if they were large enough issues to merit their own report, especially since the repro steps were identical.

Re: bug #4 -- if I want to start the viewport rendering at e.g. frame 105, it appears that I can not do that unless I change the start position of the animation ("Frame Start / End"). Meaning, the position of the play cursor is irrelevant to the start position of the animation. In my report, I was referring to the fact that having AV Sync enabled and using JACK seemed to "fix" this "bug", because rendering would start where the cursor was. But again, I cannot reproduce this now: now it starts at the beginning (Frame Start) no matter what the settings are.

May I also ask, what is your reason to use JACK?

Last I dealt with my audio config, JACK was necessary to use my audio interface as my OS default interface. (It may no longer be true.)

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

OpenGL render bugs with JACK #65584