Closed Alexees closed 4 years ago
Alexees
commented
4 years ago I dug a little through the code and if I'm not stupid, none of the Send commands are executed because neither of the Queues in SendQueue.cs are written to. Maybe I'm dumb, but I shouldn't I be getting more references for any of these than just those 3?
Alexees
commented
4 years ago Nevermind, I found the time to do a demo setup and everything is working with the components required and the documentation provided. So it is something on my side then.
martindevans
commented
4 years ago Lost samples in preprocessor insufficient buffer space
Both of these indicate that audio is not being consumed fast enough somewhere along the way so buffers of audio are filling up. It looks like the problem is in the microphone - the mic drains the entire buffer of available audio every frame and in this case that buffer is 35520 samples - which is about 750ms of audio in the space of a single frame! The preprocessor error is probably a consequence of that mic problem - the mic instantly dumps all it's audio onto the preprocessor input queue and the queue fills up faster than the preprocessor can drain it.
Usually you would see this error either as a hardware/driver problem of some kind or due to very bad framerates (i.e. a single frame taking 750ms). If you have a transient bad frame rates at a known time (e.g. during level load) try calling DissonanceComms.ResetMicrophoneCapture to flush the pipeline (discarding all audio).
shouldn't I be getting more references for any of these than just those 3
The way this works is _serverReliableQueue is not the queue itself, instead it's a LockedValue<T>. Calling Lock() returns a handle (in this case called locker) which you can access the object itself through, so you'd need to look for uses of locker.Value. This pattern makes it impossible to not take a lock on something that should be locked.
Telepathy the only choice for me.
That's unfortunate, Telepathy doesn't support unordered+unreliable packets so it will significantly amplify the negative effects of poor network conditions on voice quality. A single lost packet would normally be completely concealed by packet loss concealment - but instead Telepathy will retransmit (and delay all subsequent packets), causing a single lost packet at the network level to become a whole set of lost packets (the delay will be significant enough that Dissonance has already played past the packet by the time it arrives). It looks like Ignorance doesn't support UWP at the moment but I would guess that's just a case of needing to compile the native dependencies (ENET) for UWP, it might be worth looking into that in the future.
Alexees
commented
4 years ago @martindevans thank you for the answer, did not expect that in an already closed answer. I will see if I can do something about UWP then
I'm not sure if it is a faulty setup, but everything looks fine from a debugging perspective. I have the problem that even though the mic is clearly recording and Dissonance established a connection, the server is not receiving any data.
The MirrorIgnoranceCommsNetwork component neither shows any sign of traffic being transmitted on the client nor on the server. I tested this with Server and Client on the same machine with two seperate Unity instances.
Additionally, this is what the console logged immediately after starting up:
The setup I am using is part of a larger project and before I go in and recreate the Dissonance chat part in a new project it was quicker to ask if there is something obvious that I'm missing.
P.S.: The fact that Unity's Connected Games is still in development and the old LLAPI is the only API that I've found on the net that's capable of running on UWP AND other platforms, makes Telepathy the only choice for me.