[Released] Dissonance: Unity Voice Chat

Hey, thanks for the reply but I'm still struggling to get it to work.

So in the Client scene, I have the DissonanceSetup GameObject with DissonanceComms and UNetCommsNetwork. In the server scene, I have the exact same object. Are both those object correct in those scenes?

And the server scene only needs the DissonanceComms and UNetCommsNetwork components only in the scene?

If it doesn't need a VoiceBroadcastTrigger, then what component on the client is determining when the local player is speaking? i.e. shouldn't there be a VoiceBroadcastTrigger in the ClientScene for the local player somewhere other than the one on the proxy?

 

You should have the DissonanceComms and UNetCommsNetwork components in every copy of the scene (it sounds like that's what you have).

In your local scene you will have a broadcast trigger attached to every other player which transmits to that player (when you enter the trigger volume). So those determine when the local player is speaking.

You can see an example of this in the demo scenes (except the LLAPI demo scene, try the HLAPI one). Each player prefab has a broadcast trigger attached sending to self, remote peers then enter the trigger volume (in their local scene) and begin transmitting to the associated player.

 

I'm really sorry I just realised I made a mistake in my initial reply. I said:

But that's not right! The local IDissonancePlayer is what activates volume triggers - if that doesn't exist then none of the volume activated triggers will ever send any voice!

 

Thanks for your reply.

I'm still confused about certain aspects

You say "this will find the IDissonancePlayer and will send the voice to whichever player that represents" but the proxy prefab is simply the prefab in the client game which represents the other players in the game. How is that prefab sending voice? Shouldn't the voice be sent from the server?

So on the Owner prefab (the object the local player is controlling in his game, the client game), should there be any more Dissonance components apart from IDissonancePlayer?

-

Currently when I check on the VoicePlayback component while the game is running, it says "Positional Playback Available" is false, even though the "Use Positional Data" on the proxy VoiceBroadcastTrigger is true. What do I need to check to make that positional playback true?

 

The VoiceBroadcastTrigger doesn't actually send the voice, it's just a trigger which tells Dissonance this player wants to send voice to somewhere (a room or another player). Under the hood Dissonance is capturing the voice on each client and then sending a stream of voice packets either to the server (relayed to other peers) or directly to other peers if the network supports p2p communication.

So what you want in a local scene is a load of triggers, one for each remote player. When the local client detects that the local player enters the collision volume (using the local physics) it begins sending the voice to the right location. The server actually has almost nothing to do with it - it just acts as a packet relay - all of the logic is done on the client.

Nope, you just need an IDissonancePlayer to indicate to Dissonance that this entity is the local player (i.e. the one to use for broadcast trigger volume triggering).

Here's the HLAPI Player prefab as an example:



This isn't quite a perfect example because this prefab is used both locally and remotely. However you can see that the player has a broadcast trigger set to "Self", this means it will find the "Hlapi Player" (the IDissonancePlayer for HLAPI) and send to it. If the "Hlapi Player" is the local player then this never sends any voice. So all you really need is the IDissonancePlayer.

Positional playback is driven by the IDissonancePlayer components - Dissonance plays sound from the position of the component for each speaking player. If Dissonance can't find the player component for a speaker than positional playback will be unavailable for that player.

Here's an image from the Hlapi Player in the demo scene at runtime:



I would suggest creating an inspector for your custom player implementation (check out Assets\Dissonance\Integrations\UNet_HLAPI\UNetHlapiPlayerEditor.cs to see how to do this, it's trivially easy) which will show this same information. Once you've done that you can look at a few of your players in the scene to make sure they're showing the right thing.

- Player: Shows the "Local Player ID" for the player it represents (you can check this on the player in the Dissonance Comms inspector). If this is incorrect/blank it's probably a bug in your custom IDissonancePlayer.
- Type: "Local" or "Remote". There should be one local (with the same ID as the local Dissonance Comms component) and many remote (one per remote player).
- Tracking: Indicates if this component has registered itself as a player tracker with Dissonance (after this Dissonance wire up the playback system to play from the correct position). If this is true but positional playback is unavailable it may be a bug in Dissonance.

 

Thank you very much for your detailed reply.

Ultimately, my problem was that I was not syncing the correct player ID in my IDissonancePlayer. Once I fixed that, I got proximity voice working.

Regarding security, since the client is handling the positional audio settings, if a malicious user disables positional data from his client, will everyone in the room hear him speak? If so, how can this be prevented from the server?

-

It would also be great if the PushToTalk activation check in VoiceBroadcastTrigger.cs would not be hardcoded to use Input.GetAxis(axisName) because in my game I don't use the inputs from the Unity InputManager, but rather I check with GetKey(KeyCode) and the only way I can integrate it atm is by changing the code directly from VoiceBroadcastTrigger.cs to support it.

Thank you for your time,
// Dreas.

 

Positional data isn't much of a threat, if the player started sending voice without positional playback enabled (it's just a flag in the header of the speech packet) then the same people would hear them, but their voice would appear to be sourceless (coming equally from all directions). The real problem for security is that clients tell the server which channels they are listening to, so a malicious client could spoof a packet to subscribe to the enemy team chat, for example. Encrypting your network stream is a fairly easy step to make this a lot harder, but still leaves you open to people tweaking the memory of their local client somehow.

So as you suggested in your question, you really need server side enforcement, at least of channel subscriptions to people can't listen to things they shouldn't and ideally of voice transmission so people can't inject their voice into channels they shouldn't. Unfortunately Dissonance doesn't currently have support for either of these things. Luckily we've just rebuilt our networking system to be far more modular and extensible, so this is something we could definitely add support for in the future. If you don't want to wait for us to add it I can certainly give you some pointers for how you could implement this yourself

 

Thanks for your reply.

I'm now currently trying to write my own implementation of the network layer from the instructions in http://dissonance.readthedocs.io/en/latest/Tutorials/Custom-Networking/ and I seem to have set everything up.

But when I check the inspector of my custom DissonanceCommsNetwork inspector, it says that the connection is Degraded, and when I'm pressing the hotkey on the client, I'm getting these Warnings:
[Dissonance:Network] VoiceSender`1: Attempted to send voice before assigned a client ID by the host

Do you know which step I could be missing?

Thanks for your time,
// Dreas.

 

Both of those warnings effectively mean the same thing - a connection is "degraded" until it has been assigned an ID by the server and the VoiceSender cannot send voice until the server has told it what it's unique ID is. This probably means you're not doing something in your custom network integration so it's just sitting in this semi-connected state forever.

A few things to check. Client side:

- You must be calling Connected() somewhere. Once this is called it indicates to Dissonance it may start sending and receiving packets. In many of the network integrations this is called inside public override void Connect() immediately after doing first time setup work because the underlying network is already created and ready to go before Dissonance even exists. If you don't do this the client will never talk to the server because it'll always be waiting for this.
- You must pass all the Dissonance related packets into NetworkReceivedPacket. If you do this incorrectly you should see warnings which say something like Discarding packet - incorrect magic number. If you don't do this at all then the client will never receive any messages from the server.
- You must implement SendReliable and SendUnreliable in such a way that the server will get the messages (e.g. HLAPI uses two channels, care needs to be taken that the client and the server are using the same channels to communicate).

The server side is much simpler:

- You must implement SendReliable and SendUnreliable in such a way that the correct client will get the messages.
- This won't be the cause of this particular problem but you need to make sure that you're calling ClientDisconnected when a client leaves the underlying session.

 

Thanks for your reply.

The step that I was missing was calling Connected() on the client. Once I did that, it started working as expected.

I have noticed a problem though where even though I'm using the Positional Tracking and Proximity Chat, I still receive the full bandwidth of all the speaking players on the client from the server when I get out of range from them. I do not hear them speak (since the AudioSource has a max distance in the 3D Sound settings) but I still receive their full bandwidth.

Is this an issue from my side?

Thanks for your time,
// Dreas.

 

The player should stop sending their voice when the broadcast trigger is deactivated. If you're using proximity activated triggers then you want to make sure that the trigger volume is roughly the same size as the AudioSource range.

 

Where should the VoiceBroadcastTrigger of the local player exist in the client scene? Should it exist on the local player prefab that is running around in the world, or attached to the static DissonanceComms GameObject?

Because currently my VoiceBroadcastTrigger of the local player is attached to the static DissonanceComms object, and my local player prefab does not have a VoiceBroadcastTrigger attached.

And if it should be attached to the local player prefab, should the local player prefab also contain the sphere collider? Or should only the proxy prefabs contain the sphere collider?

 

I think you're misunderstanding what the VoiceBroadcastTrigger is for - it decides who the local player is sending to. So for proximity broadcast there is a VoiceBroadcastTrigger attached to each of your proxy objects (i.e. the objects which represent remote players in your local scene). The local instance of Dissonance then does collision detection with all these triggers and sends the voice over the network to the necessary peers.

With this in mind:

You don't meed a local VoiceBroadcastTrigger at all - because you never send voice to yourself! You can attach a trigger to the local player prefab, but it'll see that it's sending to the local player and will do nothing.

I'd suggest taking a close look at the HLAPI scene with a few players connected. You'll see a circle highlighted around every remote player, these are the VoiceBroadcastTriggers which are in your local scene and when you walk inside one of them you begin sending voice directly to that player. You'll also see that the local player does have a VoiceBroadcastTrigger component attached, but it does nothing.

 

So if I don't have a VoiceBroadcastTrigger in my scene for my local player, from where can I set to either use push to talk versus voice activation?

 

That's set per trigger. This is so you can have setups like a global chat room triggered with push-to-talk "v", a team chat room triggered with push-to-talk "b" and then a load of proximity chat rooms all triggered with voice activation.

Edit: One of your posts disappeared as I was typing my reply! If you have a particularly complex trigger control scheme to manage you could implement new trigger types which extend VoiceBroadcastTrigger and fetch the correct controls for themselves. e.g. TeamChatTrigger which then goes and configures itself to the correct control scheme.

 

Thanks for your reply.

I now have everything set up but when I now started testing with a number of players, I have started encountering some exceptions.

These are the exceptions that I'm getting on the Client Side:



And these are the exceptions I'm getting on the Server side:

I will now start investigating why this is happening. It would great if you have some pointers. I'll update the once if I discover anything.

Thank you for your time,
// Andreas.

 

Just to check, this is using a custom network integration?

The first error (argument out of range) happens when part of the network system (the VoiceSender) is told that a player has left, but they've already gone so it tries to remove someone who doesn't exist. The second error is happening when a player is added to the collection, but they already exist.

These are obviously the same root problem - events are, for some reason, being processed twice. My guess is your custom network integration is sending the same packets twice. Dissonance internally re-uses buffers so you must make sure that in your SendReliable and SendUnreliable methods you don't hold onto a reference to the array beyond that method (e.g. if you add the packet onto a queue, you must copy it to another array and enqueue that array).

The final error is happening because you're trying to write out too many bytes into a single packet. You can expand the packet size if necessary, but I suspect this is related to fallout from the first problem.

 

Dissonance 4.0.0 has just been released on the asset store!

This release includes two big new features: custom microphone capture scripts and an API to access information about who is listening to which rooms.

Custom Microphone Capture Scripts
With custom microphone capture scripts it's possible to write a new script which captures audio data and feeds it in to Dissonance. This allows you to take complete control over what audio data is fed into Dissonance. Check out the documentation for the details on how to implement this.

Remote Rooms API
We've added some new properties and events which expose which rooms remote players are listening to. Check out the release notes for details on how to access this data.

Breaking Change
This is an increment from 3.0.3 to 4.0.0, so that means there's a breaking change. The ICommsNetwork interface (only used if you are implementing a low level custom network backend) has two new events to raise when remote players enter and exit rooms. Check out the release notes for the details.

 

Enter the Devdog Christmas Giveaway for a chance to win a free copy of Dissonance!

 

Dissonance 5.0.0 has just been released on the asset store!

This release includes two new features: Steamworks peer to peer networking integration and an API to access information about which channels people are speaking through. See the full release notes for all the details.

Steamworks P2P
With this integration games can use the steam network system to setup a voice chat session - once this is running voice traffic is sent directly from peer to peer. Check out the quick start guide to find out more.

Remote Channel API
This new API exposes information about how you are hearing voice from a player. Call GetSpeakingChannels to get a list of all the channels that a player is speaking to you through. Check out the documentation for the details on exactly how to use this.

 

Hello @Nyarlathothep

after updating to Dissonance 5.0.0, we started to get this error message (on the client):

[Dissonance:Network] VoiceSender`1: Attempted to send voice before assigned a client ID by the host
UnityEngine.Debug:LogWarning(Object)
Dissonance.LogMessage:Log() (at Assets/Plugins/Dissonance/Core/Log.cs:103)
Dissonance.Logs:WriteMultithreadedLogs() (at Assets/Plugins/Dissonance/Core/Log.cs:124)
Dissonance.DissonanceComms:Update() (at Assets/Plugins/Dissonance/DissonanceComms.cs:519)

Steps to reproduce are:

1) Start a standalone server application
2) Start a client
3) Disconnect the client
4) [our server calls NetworkManager.Shutdown() and starts the server again]
5) After restarting the client, the problem appears (no problems show up on server debug out)

We did not encounter this issue with Dissonance 3.0.3 / 4.0.1. The key is the step 4, without it there is no error. On server side, I needed to add a nullref-check against NetworkManager.singleton on line 41 in HlapiCommsNetwork.cs (this was not needed either on previous versions).

Any ideas to properly solve this?

Thanks a lot in advance!

 

Hi fakeunityuser2

> Attempted to send voice before assigned a client ID by the host

This warning is generally harmless - is it causing problems?

The cause is that when a client starts up there's a race between the local client sending voice and the remote server assigning an ID. This may cause a very small amount of voice to be discarded if you attempt to send during the setup phase (which lasts for roughly 2 network round trips). Of course if the warning persists for a long time that's something that needs fixing!

> nullref-check against NetworkManager.singleton on line 41 in HlapiCommsNetwork.cs

Having a look at the code for Shutdown it does looks like a null check should have been there. I'll add this to the next version!

 

Hi Nyarlathothep,

and thanks for the reply! The warning indeed is causing problems. No audio is going through the network after the warning appears, and it is printed every frame after that.

To reiterate, this starts to happen after NetworkManager has been reinitialised. This did not happen with previous Dissonance versions. Other than calling Shutdown, I do not do any other special (de)initialisations.

Any ideas?

 

Well that's definitely a problem! Could you open up an issue on the issue tracker with a complete description of the problem and some logs from both the sender and receiver ends. If you can show an example of exactly what you do with shutdown/re-initialisation that'd be very helpful too.

Before capturing the logs go to Window > Dissonance > Diagnostic Settings and change the categories to:
- Core: Trace
- Recording: Debug
- Network: Trace
- Playback: Debug

This will spam a lot of messages into your log which can be quite bad for performance so remember to set the, back to Info after you're done!

> Any ideas?

This should only happen right at the start of the session - once a client is assigned an ID it should never lose that ID until it leaves the session. My guess is the client state isn't quite reset properly when the network is re-initialised - i.e. the ID is reset (causing the issue) but it's not set into a state where it asks for a new ID (so it gets stuck in limbo). Hopefully the logs will confirm this.

 

Actually,

after more careful investigation it appears that the problem is present also with previous versions of Dissonance (3.0.3 and 4.0.1). But it only happens when a Win64 build is acting as a server. This is regardless if I am running the server on a standalone machine or in a machine where I have also clients.

Most of the time we use a headless Linux build to act as a server and with this there are warnings (or problems). The code is the same for both platforms, so I don't know what could cause this.

I will investigate this a bit more with your debugging suggestions.

 

Dissonance 6.0.0 has just been released on the asset store!

This is an incredibly exciting release because it brings something we've been working on (and promising) for a long time...

Acoustic Echo Cancellation
Acoustic Echo Cancellation (AEC) watches the sound coming out of your speakers and then when the microphone records it a few milliseconds later it automatically removes it from the recording. This prevents painful feedback loops, hearing echoes of your own voice coming back to you and even suppresses game sound effects from being transmitted! Since this is such a complex feature we're marking this as an experimental feature - please email us feedback if you use it and tell us what does and does not work. Check out the setup documentation for more details.

Flexible Encoding Settings
Another big change we've made with this version is how encoder settings are configured. Previously all Dissonance clients had to use the same encoder settings, this is no longer the case. Now clients transmit their settings over the network when they join the session - this allows you to choose the best settings for each platform your game runs on.

 

I posted on the reddit forum, but figured I'd put it here too. Switching microphoneName doesn't seem to do anything except change the UI to read a different source. The original mic is still the only device that gets picked up on Dissonance (I've switched via code and I've switched via the UI in the editor, and both do nothing).

 

Hi KamiKaze425,

I've just checked locally that it's working, are you on the latest version of Dissonance (6.0.0)? If not I'd definitely suggest updating.

If you are already on the latest version (or you upgrade and the problem persists) could you send me an editor log (martin@placeholder-software.co.uk). Before capturing the log go to Window > Dissonance > Diagnostic Settings and change all of the log levels to Debug. Thanks

 

I'm fairly positive I'm on the most recent. I deleted all the Dissonance files and re-downloaded Dissonance off the Asset Store. Can you show me the code you're using to switch mics?
I just used:
comms.MicrophoneName = Microphone.devices[1];

where comms is a public variable to DissonanceComms that I attached in the scene.

 

I just switched it in the Editor:



I switched from my desktop mic (default) to my oculus mic and back again. I confirmed it was working by whispering to the relevant devices and seeing if I could hear myself. You can find the code behind that at BaseIMicrophoneCaptureEditor.cs Line 73 if you're curious. The code you show should work, so this could be a bug in Dissonance.

Could you double check the version you're on in Window > Dissonance > Integrations and if it is indeed the latest (6.0.0) send me the editor log with the settings I mentioned in my previous post. Thanks

 

Yup, it says 6.0.0. And I'm doing the exact same thing as you and get a different result D:
Are you using UNet HLAPI? Would that possibly make a difference?

Here's the log

 

I've had a look through that log and it looks like everything is ok :/

There are two relevant entries in the log:

Line 1532: [Dissonance:Recording] (01:20:54.524) CapturePipelineManager: Changing microphone device from '' to ''
Line 2626: [Dissonance:Recording] (01:21:00.277) CapturePipelineManager: Changing microphone device from '' to 'Microphone (Realtek High Definition Audio)'
​

The first time obviously doesn't change anything interesting - it's probably just changing from a null string (indicating the default device) to an empty string (also indicating the default device). That's actually a very minor bug (which I have just fixed) because it shouldn't cause a change, but that's not a problem.

The second time changes from your default device (whatever that is) to the Realtek HD audio device. After this line there are some other entries in the log indicating that the microphone capture system resets itself and starts recording, indicating that the change does seem to have worked. Could you try putting this into BasicMicrophoneCapture.cs around line 100, immediately before the return statement:

Log.Error("Started recording with: {0}", _micName); // <---- insert this line!
return _format;​

With that line in place when you change the device you should get a big red error message in the log confirming exactly which device is in use.

My suspicion is that the realtek HD audio device is in fact your default device, which would explain why you're never seeing any change!

Edit:

> Are you using UNet HLAPI? Would that possibly make a difference?

Oops, forgot to answer this. Yes I was using HLAPI in the gif. No it shouldn't make a difference.

 

My USB headphones are both my default device and default communication device. The Realtek HD one is just a simple microphone plugged into the microphone jack of the computer.

And I also use the editor UI to jump to different devices (like the microphone in my Vive headset) and it still doesn't change.

I keep getting this red error now that I have that Log.Error you asked me to put in.

Code (CSharp):

1. [Dissonance:Recording] (19:17:59.469) BasicMicrophoneCapture: Started recording with:
2. UnityEngine.Debug:LogError(Object)
3. Dissonance.LogMessage:Log() (at Assets/Plugins/Dissonance/Core/Log.cs:106)
4. Dissonance.Logs:SendLogMessage(String, LogLevel) (at Assets/Plugins/Dissonance/Core/Log.cs:135)
5. Dissonance.Log:WriteLog(LogLevel, String) (at Assets/Plugins/Dissonance/Core/Log.cs:218)
6. Dissonance.Log:WriteLogFormat(LogLevel, String, String) (at Assets/Plugins/Dissonance/Core/Log.cs:227)
7. Dissonance.Log:Error(String, String) (at Assets/Plugins/Dissonance/Core/Log.cs:450)
8. Dissonance.Audio.Capture.BasicMicrophoneCapture:StartCapture(String) (at Assets/Plugins/Dissonance/Core/Audio/Capture/BasicMicrophoneCapture.cs:101)
9. Dissonance.Audio.Capture.CapturePipelineManager:RestartTransmissionPipeline() (at Assets/Plugins/Dissonance/Core/Audio/Capture/CapturePipelineManager.cs:234)
10. Dissonance.Audio.Capture.CapturePipelineManager:Update(Boolean, Single) (at Assets/Plugins/Dissonance/Core/Audio/Capture/CapturePipelineManager.cs:132)
11. Dissonance.DissonanceComms:Update() (at Assets/Plugins/Dissonance/DissonanceComms.cs:547)
12.  

It looks like _micName is never being set to the new choices for me

 

Now the names are printing this next time after I added another log.error, but the "mic amplitude" still only moves if I speak into the original USB headphones

 

That's really strange. I even changed my default device to the other mic, and it would only use the original USB mic. I closed Unity and relaunched with the realtek mic as default, and now that mic is the only one that works even when I change the devices on the dissonance UI

I'm using Unity 2017.2.0f3

 

Unfortunately I think this is probably a Unity bug, but let's double check before passing it on to Unity. Could you put a debug print immediately before the call to Microphone.Start (BasicMicrophoneCapture.cs Line 68) which prints out the _micName. This is where we ask Unity itself to give us Audio data from the named device - if that prints out the name you set but it's supplying data from the wrong device that's a Unity bug

If it turns out that it is a Unity bug could you share the Unity ticket with me. I'll add it to our own issue tracker so we can keep an eye on the resolution for it.

 

Everything seems to be printing correctly. But it's definitely not working
The only thing weird I did notice is that everything is getting printed twice when I change the microphone. It seems like StartCapture is being called twice when I change it, even through the UI.
I wonder if I updated my Unity if it would fix... but this project is almost done and extremely large. I don't want to update and have something else break, haha.

StopCapture also gets called twice.
StopCapture -> Microphone.Start -> return _format -> repeat once

 

Also, if I click outside the editor window then click back in. StartCapture gets called again. Maybe because it lost and regained focus? But only gets called once.

 

Soooo I think it's definitely a Unity Bug. Because I have a little script that just plays Microphone.Start into an audioSource locally, and that won't let me switch microphones either... joy...

 

> StartCapture is being called twice ... Maybe because it lost and regained focus?

Realtime audio processing is very sensitive to framerates, unfortunately interacting with the Unity editor UI very often causes huge frame rate hitches. Dissonance has a detector for large skips in time in a single frame which resets the capture system (part of which involves calling StartCapture). I would guess that the first time you see StartCapture get called is because of you changing the device, and the second time is because you just interacted with the UI and caused a time skip which caused Dissonance to reset it's capture system. So long as the latest StartCapture call shows the correct device you're ok.

> I wonder if I updated my Unity if it would fix

I'd report the issue to Unity first and see what they say. We have plenty of people using Dissonance on 2017.2 so this must be a fairly rare issue, which means it's unlikely to have already been fixed in 2017.3.

 

What version of Unity were you using in the gif you sent me?

 

Also, there's already a bug being tracked
https://issuetracker.unity3d.com/is...ding-the-audio-from-selected-recording-device

 

I was using Unity 5.6.2f1, which explains since I didn't see the problem since that issue lists this as a regression in 2017.2f3.

By the way I've opened an issue on our own issue tracker so we can keep an eye on progress with this.

 

Sounds good. Thanks for the help. This really sucks for us though, haha. Being able to switch the mic on Dissonance was the cleanest solution to a problem.

 

There is an alternative which may help as a workaround if you're short on time and can't wait for Unity to fix this. It's possible to write your own audio capture systems (docs: https://dissonance.readthedocs.io/en/latest/Tutorials/Custom-Microphone-Capture/) - so you could write something which directly accesses e.g. WASAPI on windows and bypasses the bug in Unity.

Obviously this would be quite complex so you'll only want to do this is you're on a deadline!

 

Hi!
It's possible to try a game or a demo that uses your plugin? I would like to try how it works before buying it.

Thank you in advance!
Nick

 

Hi Nick,

We don't have a demo publicly available at the moment but if you contact me by email (martin@placeholder-software.co.uk) I'll compile one of the built in demo scenes and send you that

 

It doesn't seem to be fixed in 2017.3 so I'm not sure when it'd get fixed. Do you think I can get a little more direction on how to create my own audio capture that bypasses the Unity bug I'm experiencing? Do you have any links to examples maybe from other customers?
Thanks

 

The issue status at the moment is "fixed in future release" so I would guess that it'll be fixed in the next major release (2018.2?). I'm rather disappointed that Unity aren't backporting a fix to something they broke in a fairly recent version! Would it be possible to downgrade the project to 2017.1 - the issue says that the problem was not reproduced in 2017.1.3f1, so that may be an easy workaround if you're not depending on 2017.2 features.

I've written an explanation of what needs to be done here, and I'm happy to answer any specific questions you have either here or by email

I will warn you that this will be quite complex! You'll probably have to load up something like NAudio and pull data directly from one of the sound systems available though that. This will be extra complex if you're trying to support multiple platforms!

 

This is like a 30GB project that is soon to be released. I'm not sure what new bugs would arise if my other plugins are using certain features. So I'd rather not change versions if I don't have to. Although I'm running into a DLL bug as well, so I may have to if I can't find something for that as well.

I'm not supporting multiple platforms. Only windows. It's a VR game. So hopefully it wouldn't be too complex.