Positional audio issues

[doctormothra]

Hi, I've been using Mumble for a couple of years now and it's helped in our VR apps a lot! I have an issue with positional audio in my own app though. It works fine after a few seconds but on initial connection it seems to take a while for the positional audio to take affect, resulting in hearing everybody else for a short time. I've integrated the positional audio just as specified on the Mumble website and for the most part it's not a problem, only on initial connection to the server. I'm using windows (XP and 7) and have the same issues on both OS's.

I'm using Mumble 1.2.3a

Has anyone got any ideas as to why this happens or ways to alleviate it?

Thanks.

[kissaki]

No idea what VR apps is.

So you integrated pos audio via Link?

Does Mumble log the linking more responsive (/faster) then it takes effect?

[doctormothra]

Hi, sorry should have explained what VR is. VR = virtual reality. We essentially build collaborative virtual environments where we communicate via video and audio means. The audio is handled via Mumble.

Yes, I use Link to implement the positional audio.

I'm not sure what your response actually means, could you expand upon it please?

Cheers.

[kissaki]

Mumble has a message log area, which logs chat messages and should also log when a pos audio plugin becomes active/linked.

Does it do so? Tell you it linked to xy?

[doctormothra]

Hi, yes the plugin gets linked fine. Everything appears to work correctly, it just takes some time.

Thanks.

[hacst]

The link delay is an artifact of Mumble's way to check the plugins. The list of plugins is constantly stepped through attempting to trylock one plugin after the other with a fixed delay of 500ms before the next plugin is checked.

Up to now we haven't considered this to be a problem as linking usually happens on game startup from which it takes quite a bit of time before actually entering the game. You are the first to complain ;)

We now have 36 plugins which would mean a worst case waiting time for 18 and an average waiting time of 9 seconds for a lock of any specific plugin. Is this about what you are seeing?

[doctormothra]

Hi, thanks for the reply. Yes, a 9 or 10 second delay is exactly what I'm seeing. Usually it isn't too much of an issue for me either as we schedule clients to start early in the morning, but if we have to start the clients during the day then it becomes more troublesome.

Thanks.

[hacst]

If you control the installations and only care about one plugin you could deactivate auto plugin updating and simply delete all other plugins. That should cut down link time to 0.5s worst case.

Also there's no real reason for us to poll at 2 Hz. If you create a feature request to change that behavior chances are good it will at least receive a speed boost ;)

[doctormothra]

Ok. I'll delete all the other plugins and see what happens. I'll try this when I'm back in the office tomorrow and let you know what happened.

Thanks very much.

[doctormothra]

Hi, this has certainly helped issues, the delay is now much less, although still there, probably 2 or 3 seconds now. I'll investigate to see if it's anything in my app that is contributing to the problem. Thanks for your help, much appreciated.