VOIP muted with Audiomixer enabled

I’m at wit’s end with this one. I started working with the new Audio Mixer for a VR project and finally got Steam Audio to package and apply its effects, but it looks like VOIP audio won’t play anymore. The speech bubble indicators are still synced fully on all clients, so the voice is getting transmitted over the network… but the voip audio just isn’t playing.

I can get voip working again by removing this line from my WindowsEngine.ini file:

[Audio] AudioDeviceModuleName=AudioMixerXAudio2
But then obviously Steam Audio falls apart and I’m back to the old audio engine. I haven’t found anything in the logs that indicate failures. Any idea where I can begin to figure out what’s going on here? I’m doing just about everything in Blueprint right now.

I believe you cannot make this work without modifying the relevant engine code to enable async processing of the voice. This will likely be updated in the future that will enable the feature for you, so i guess you can either just wait and go without the voip feature for the moment, or modify the engine code, or create your own voip component that have the setup required for async proc. Afaik the new Audio Mixer is only an experimental feature so far, don’t expect everything works as smooth :slight_smile:

It helps to specify which version of the engine you’re on. Audio mixer is still experimental and we’ve not quite tested all cases yet! I think the issue might be that the VOIP stream is using a USoundWave vs a USoundWaveProcedural and the audio mixer is casting to a USoundWaveProcedural in the lower level code. Somebody else ran into this.

I think if you change the async task ptr in FMixerSource::ReadMorePCMRTData for bProcedural case to USoundWave vs USoundWaveProcedural and avoid the cast, it should work.

In any case, this should definitely be fixed since we recently used VOIP in audio mixer for our last SIGGRAPH demo.

Thanks for the insight! I’m on the latest release (4.17.1). I’ll check on GitHub to see if it’s in the pipe for the next bugfix release, but if it’s not around the corner I can try tweaking the engine myself.

@Minus_Kelvin - thanks. I can’t tell if the fix is on GitHub, but that’s OK.

Just so I understand before I get too deep into the engine tweak - I think you’re suggesting that I try the following:

  1. Change [FONT=courier new]FProceduralAudioTaskData.ProceduralSoundWave from [FONT=courier new]*USoundWaveProcedural to [FONT=courier new]*USoundWave
  2. Remove the cast in the line [FONT=courier new]NewTaskData.ProceduralSoundWave = Cast<USoundWaveProcedural>(WaveData);

I’ll give this a shot and see how it goes!

That hotfix didn’t end up working, though I didn’t get to try debugging what more needed to be done. I think I’ll see if it’s any better just working off the master branch.

@Zenteran @Minus_Kelvin
I have been submitted a pull request to solve this issue. Can you please confirm that it makes VoIP work on your end too?

@Minus_Kelvin is it possible that this was a missing setup for the new audio mixer feature to process the voice?

For what it’s worth, I can confirm that a custom engine build of 4.17.1 + this fix solved my own “muted voip” problem! My project has Steam Audio, AudioMixerXAudio2, and OnlineSubsystemSteam configured, for context.

Thanks for the confirm, i have updated the PR to mention your results!

@Minus_Kelvin Can you please review this comment to help me figure out whether the async processing must be evaluated properly for the MAC platform in case of voice capture, or that does not apply to the situation with online subsystem?

Relevant commit that added this directive: