This is a read-only archive of the Mumble forums.

This website archives and makes accessible historical state. It receives no updates or corrections. It is provided only to keep the information accessible as-is, under their old address.

For up-to-date information please refer to the Mumble website and its linked documentation and other resources. For support please refer to one of our other community/support channels.

Jump to content

Positional audio issues


doctormothra
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Administrators

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Administrators

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 ;)

Link to comment
Share on other sites

 Share

×
×
  • Create New...