Cool VL Viewer forum
http://sldev.free.fr/forum/

Parcel audio broken and slow SLPlugin startup in 1.26.21.14
http://sldev.free.fr/forum/viewtopic.php?f=4&t=1827		 Page 1 of 2
Author:  Amalia Illios [ 2018-03-27 16:12:09 ]
Post subject:  Parcel audio broken and slow SLPlugin startup in 1.26.21.14
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.

Attachments:
logs.tar.gz [37.53 KiB]
Downloaded 191 times
Author:  Henri Beauchamp [ 2018-03-27 16:20:53 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
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...
Author:  Henri Beauchamp [ 2018-03-27 17:20:56 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
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.
Author:  Henri Beauchamp [ 2018-03-27 22:53:17 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
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... :cry:

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).
Author:  Amalia Illios [ 2018-03-28 14:38:03 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
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. :oops:

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
Author:  Henri Beauchamp [ 2018-03-28 14:59:50 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
Amalia Illios wrote:
Good to see it's not all in my mind.
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).

Quote:
So, is that just the explanation for the no parcel audio thing, or does this also cover the slow SLPlugin startup?
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...

Quote:
If not the latter, is there some way to get some debug output from that?
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.
Author:  Amalia Illios [ 2018-03-29 14:51:19 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
Hello again Henri,

you wrote:
Henri Beauchamp wrote:
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.
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. :lol:


Love,
Lia
Author:  Amalia Illios [ 2018-03-29 15:26:37 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
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):
Code:
[0329/165728.090432:VERBOSE1:multi_log_ct_verifier.cc(75)] Adding CT log: Certly.IO log
[0329/165728.119584:VERBOSE1:navigator_impl.cc(239)] Failed Provisional Load: file:///home/CoolVLViewer-1.26.21.10/skins/default/html/en-us/loading/loading.html, error_code: -3, error_description: , showing_repost_interstitial: 0, frame_id: 2
[0329/165728.119958:VERBOSE1:network_delegate.cc(30)] NetworkDelegate::NotifyBeforeURLRequest: http://viewer-login.agni.lindenlab.com/?lang=en-us

And in the .14 startup -- delay (26.3 seconds):
Code:
[0329/165807.033277:VERBOSE1:multi_log_ct_verifier.cc(75)] Adding CT log: Certly.IO log
[...]
[0329/165833.340357:VERBOSE1:network_delegate.cc(30)] NetworkDelegate::NotifyBeforeURLRequest: file:///home/CoolVLViewer-1.26.21.14/skins/default/html/en-us/loading/loading.html
[...]
[0329/165833.373483:VERBOSE1:network_delegate.cc(30)] NetworkDelegate::NotifyBeforeURLRequest: http://viewer-login.agni.lindenlab.com/?lang=en-us


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


Love,
Lia

Attachments:
slostart.tar.gz [24.49 KiB]
Downloaded 191 times
Author:  Henri Beauchamp [ 2018-03-29 16:13:46 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
Amalia Illios wrote:
Maybe you can make something of it, I have no idea what the difference might possibly be. :?
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...
Author:  Amalia Illios [ 2018-03-31 08:30:25 ]
Post subject:  Re: Parcel audio broken and slow SLPlugin startup in 1.26.21
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
Page 1 of 2 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/