UniVoice 4.x.x: Upgrade guide

A lot has changed between UniVoice v3 and v4, however I've tried to keep the new things "mirror" some old patterns as much as possible.

There's no way to upgrade from v3 to v4 without code changes, so getting familiar with some key changes can help.

In this post I'll be comparing the sample code for v4 and v3 and try to describe the differences that have been made.

v4 sample

v3 sample

Namespace changes

In v3 you'll notice these namespaces 
Adrenak.UniVoice.UniMicInput 
Adrenak.UniVoice.AudioSourceOutput 
Adrenak.UniVoice.AirPeerNetwork 

This is a remnant of the previous multi-repo approach where each repo had their own namespaces. UniVoice changed to a mono-repo one as described in an earlier post with the key reason being ease of maintenance and integration.

From v4 onwards, you can expect to need only the following namespaces:
Adrenak.UniVoice.Networks;
Adrenak.UniVoice.Outputs;
Adrenak.UniVoice.Inputs;
Adrenak.UniVoice.Filters;

With all related implementations being under the same namespace. For example, OpusEncoder, OpusDecoder, RNNoiseFilter are all implementations of IAudioFilter and are under Adrenak.UniVoice.Filters namespace

This would be the case for "official" implementations. For your own, you of course can use any namespace. 

UniVoice no longer allows you to host, create, join or leave the chatroom

The IChatroomNetwork interface used to allow you to handle the lifecycle of the network, as seen under the "METHODS" region here

However after v4, UniVoice now only reacts to your network state. It only tells you if the device has connected/disconnected or a peer has connected/disconnected. It does so using the events of the underlying networking plugin. For example, the MirrorClient implementation of IAudioClient<T> internally hooks on to the Mirror events to invoke the events provided by the interface.

This allows you to handle networking via the underlying plugin with univoice never interfering with it. Univoice only "piggybacks" on the underlying networking plugin to send data.

ChatroomAgent replaced by ClientSession<T>

Major changes were made to the IChatroomNetwork interface in v3 and it was split into IAudioClient<T> and IAudioServer<T> which allowed implementing the server and client code for a network to be written in two different classes. To handle the lifecycle of a client, the ClientSession class was created which replaces ChatroomAgent.

Notice here: v4 vs v3 that their constructions are similar and provide similar events that can subscribe to.

Filters to change incoming and outgoing audio
Audio can be processed before it leaves and after it arrives. This has been added as IAudioFilter interface which can be implemented.

In the v4 samples, you can see the Opus encode and decode filters being registered during initialization to ensure that outgoing audio is encoded and incoming audio is decoded properly.

Similarly, a noise filtering filter called RNNoiseFilter has been introduced in version 4.2.0. Read more about it here

Concluding

This post along with comparing the v3 and v4 samples, and reading through the comments in the v4 samples is the best way to get familiar with the breaking changes that has been introduced.

As usual you can reach out to me via email or discord. Links available on the menu of this page.

Comments

Post a Comment

Popular posts from this blog

UniVoice 4+: Now a mono repo

UniVoice has been around since Jan 2019 and has been evolving towards becoming a robust VoIP solution for Unity. Recently I released version 4.x, which is a big upgrade from v3. One of the things that's changed is that UniVoice is now a mono repo. Why mono repo Previously the main repository only housed the interfaces and implementations for them were separate repositories . This caused a lot of pain for both me and any users of UniVoice. For me because if I wanted to change something in, let's say, the univoice-unimic-input  repository. I would need to open UniVoice, change the manifest to point to a local copy of the univoice-unimic-input repo so that I can test the changes locally.  For users because when they'd install the univoice package, it wouldn't really have anything usable. They'd need to install implementation packages separately. In v3, to get UniVoice to work you needed at implementations of at least three interfaces: IAudioInput, IAudioOutput and ICha...
Read more

UniVoice 4.4.0: Easy drag and drop integration with Mirror (also, YouTube tutorial)

Image
A tutorial for this blogpost is available on YouTube I've recently helped a lot of people setup a basic UniVoice integration in their projects. And it became clear that the sample scene is not minimal enough. The sample scene is basically an example app that also does some UI stuff. Going through the code shows how it can be used. But what most people are looking for is to get basic voice chat working as soon as possible. I've seen some people adding the example app script to their scenes, which will not work as expected. For this reason, I have now created a basic setup sample that provides a component that you can just add to your Mirror Network manager and get voice chat working immediately. This UniVoiceMirrorSetupSample.cs  easily allows you to check if voice chat is working by making sure you have setup UniVoice properly, pretty much just adding the UNIVOICE_NETWORK_MIRROR  compilation symbol to your Mirror project. The script also provides access to the IAudioServer<...
Read more

UniVoice 4.3.0: Easy Push To Talk

Push to Talk is a popular feature to: * Encourage users to user voice chat more intentionally * Reduce CPU and bandwidth usage on both the client and the server * Avoid excess chatter when connected to several peers as they'd all be transmitting audio without it Old approach using VoiceSettings UniVoice provides a VoiceSettings class that allows a client to mute or deafen a peer.  In theory, this can be used to create a push-to-talk feature. However this isn't as straightforward. After modifying VoiceSettings , you need to call SubmitVoiceSettings() to sync it with the server. The server then makes sure that the audio you send to it doesn't get sent to anyone. Usage would be like this: session.Client.YourVoiceSettings.deafenAll = true; session.Client.SubmitVoiceSettings(); This isn't too bad, but there are a couple of limitations: * Syncing the settings with the server takes a while, so it's not as instantaneous. * The client still continues to send audio to the s...
Read more