[CinCV TNG] LV2 plugins: sluggish display and other problems

Good Guy good1.2guy at gmail.com
Wed Jun 20 15:45:26 CEST 2018


I am not exactly sure which sluggish you may mean...

One way may be that the audio is "behind" the graphics.  That may occur
due to buffering ahead, and the display is showing the data being preloaded
to the audio device buffers.  In this case the display is ahead of the
audio.

Another way is that the refresh rate for the graphics is too low, perhaps
less
that 10 frames per second.  In the current implementation, the data is
routed
from the plugin stack to shared memory, and an lv2 client process is
signaled
to apply its function to the shared buffer, then it signals the plugin
server that
the data is ready.  This has to happen faster than the data demand by the
audio playback device, or the audio will be broken and choppy.

The audio device buffering uses a ring of 3 buffers, each of the size set in
the playback preferences, to load audio data to the device interface.  The
big
weakness is that the lv2 data path is serialized during its operation, so
every
delay counts, no parallel operation during its computation.  Even scheduling
delays count.   Here is a short example:  lets say you are using a laptop
with
4 cpus, and the linux kernel schedules 200 times a second.  Now, lets say
you are using the composer (4 tasks per playback engine), main window
(tracking
updates), patchbay (audio levels), and popup a few lv2 plugs (ouch).  Each
needs say 10 or so operations per second... suddenly the 800 cpus slices
you had to start is dwindling fast.  We are going to need full power Scotty.

The buffering depth is definitely the easiest way to control the playback
data latency.   If you set it up, the display is ahead, but the audio is
smooth.
If you set it lower (4096 is 4096 samples / 48000 samples/sec = 0.1 sec)
then the computer only has a few tenths of a second of data to cover all
of the delays, but the data looks more synced up.   I sort of like 8K or so,
but I have a bigger system with lots of cpus.  You will have to tweak this
until the trade off is most pleasing.

The gui's are also serialized in the client, as so they are a big drain
when they are updating.  Don't use the guis when streaming is important.
The text guis are much more efficient if you are just observing operation.


gg
PS.  In this implementation, there is no jack.  My experience is jack
deficient.
Cinelerra could use a jack device interface, but it is not currently a
priority.


On Wed, Jun 20, 2018 at 12:42 AM Olaf <cinmail at womentie.de> wrote:

> Inertia solution: Lower the samples in the playback buffer to 2k, for
> example.
>
> Point two seems to be a rather local phenomenon, also due to the lack of
> many similar observations. I guess it's connected to the routing of the
> entire audio output via Jack. In this case, this unusual correlation
> requires an innovative solution.
>
>
> _______________________________________________
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
> http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20180620/d4db0c55/attachment.html>


More information about the Cinelerra mailing list