Cool VL Viewer forum

Hello Henri,

as the subject implies, I noticed that parcel audio no longer works for me with 1.26.21.14. I also noticed that SLPlugin instances take a "very long" time now to start up (close to 30 seconds, whereas it was with virtually no notable delay before -- see the logs).

I can't really say exactly which update broke it, but the .10-release I still have around does still work fine, whereas the .14 shows the issues mentioned above. Logs of back-to-back short sessions with each from a moment ago attached. I hope this helps.

Love,
Lia

P.S.: During the long SLPlugin startup now, the relevant process does peak at 100% CPU for the time it takes until content is displayed in the viewer, then it settles down again.

Are you using the official build, or is it a self-built viewer ?

I cannot reproduce your issue here, under Linux, also there has been no change to the audio backend between 1.26.21.10 and 1.26.21.14, the only difference being a new set of libraries. So my guess it's an incompatibility with one of your system's library...

Try using another backend than Pulseaudio, for example (ALSA) and see what happens...

In fact, it could be a compatibility problem with the bundled OpenAL and FMOD Ex libraries. Try this:

In the viewer installation lib/ subdirectory, rename libopenal.so.1 to, for example, libopenal.so.1.off, and restart the viewer.

Then once logged in, from the Advanced -> Media menu, select "Disable FMOD Ex" and click on "Restart audio engine" (this will enable the OpenAL sound backend and it will use you system's OpenAL library).

Of course, you will need OpenAL installed on your system's from its own packages.

Ok, I managed to reproduce the issue here. It looks like FMOD Ex (the 64 bits library only; the 32 bits one is ok) dislikes jemalloc...

I will implement FMOD Studio support (which alas does not support OSS any more: only ALSA and Pulseaudio) and see if it fares better, else it means that jemalloc will have to be disabled (too bad, because it brought a very nice fps rate boost !).

The OpenAL backend works however (once you remove or rename libopenal.so.1, that I will also remove from the distribution package).

Hello again Henri,

It's the official build. Ever since you have been supplying 64-bit binaries, I've decided to be lazy again and use that.

Good to see it's not all in my mind. So, is that just the explanation for the no parcel audio thing, or does this also cover the slow SLPlugin startup? If not the latter, is there some way to get some debug output from that?


Love,
Lia

Well, good news: FMOD Studio is happy with jemalloc, so I'll switch to it for next release. FMOD Ex will still be usable, but the default for v1.26.21 will now be FMOD Studio, and the latter will be forced for Linux 64 bits builds with jemalloc. The only issue with FMOD Studio under Linux is its lack of OSSv4 support (but few people must be using it, and the OpenAL backend can deal with OSS, or the ALSA emulation of OSS could be used).

I did not see any such delay, so it could possibly be another issue... Try switching to OpenAL (from Advanced -> Media, and do restart the audio engine from there too after disabling FMOD and enabling OpenAL), and see if the same delays occur...

You could set the "MediaPluginDebuging" debug setting to TRUE (note that it will cause plugins to issue messages on the stderr output, so you will need to run the viewer from a terminal to see them) and/or the Plugin* debug tags.

Hello again Henri,

you wrote:Ok, I will have to look into that, then. The switch to OpenAL helped with the parcel audio, but the startup delay for the SLPlugin is still there. Usually I wouldn't mind, but the 100% CPU load while the instances load aren't fun -- especially when you arrive at a place which has several MOAPs. That's when even my octacore starts grumbling a bit.


Love,
Lia

Hello again Henri,

well, that wasn't all that exciting, except confirming what I already knew.

I did attach the logs from viewer startups (just waiting until the login screen is fully loaded, then quitting right away, as the delay happens even there). All I can see that yes, the delay is there.

In the .10 startup -- more or less instantaneous (.03 seconds):
And in the .14 startup -- delay (26.3 seconds):

Maybe you can make something of it, I have no idea what the difference might possibly be.


Love,
Lia

Apparently, Dullahan (nothing to do with SLPlugin, I think) doesn't like much your system, but the reason is unknown to me... I cannot reproduce this issue here, where the login HTML page always shows in under 5s (even when after a fresh system boot, i.e. before the executables and libraries are loaded or cached in memory) and without CPU load spike... The good news is that Dullahan is updated often, so the issue might resolve itself in a near future...

Hello again Henri,

just for my understanding ... I thought SLPlugin is the general process that provides external media capability to the viewer, and it in turn then goes ahead and uses whatever is the en vogue flavour of the week to render the content? So Viewer <-> SLPlugin <-> Dullahan | Plain CEF | Webkit?

My observation using top is that SLPlugin starts, ramps up to 100% right away, stays there and then as soon as the Dullahan process crops up in the process list, SLPlugin normalizes again. The content is rendered in the viewer momentarily after that. Very weird, almost as if SLPlugin was busy-polling for an initial reply from Dullahan or something ...


Love,
Lia