Different radios steps on eachother

[Temilit]

If someone is talking on UHF while another pilot transmits om VHF the audio will cancel out eachother (distort eachother)

UHF and VHF should not interfere with eachother (VHF should not interfere with VHF if different radios on different channels even)

This is very annoying when playing with internal flight coms aswell as Human-ATC and/or human-AWACS It's been reported with intercom aswell

[ciribob]

See this post: https://forums.eagle.ru/showpost.php?p=2936789&postcount=1029

Quote:

For the intermittent audio distortion - I still need more recordings under as many conditions to diagnose, so please send them (Twitch, YouTube, MP3) if you have them. I have one idea that I might try if I get time on Sunday but time is at a premium for me at the minute.

Its nothing in the code that causes it as far as I can see. I cant replicate locally no matter how many radios I talk on at once. If you can send me recordings that would be very helpful as without being able to replicate, I cannot fix it.

Please could you also try talking over each other while ALL in spectators and see if it still distorts? I've heard from one person that it only distorts when you're in an aircraft, not in spectators. If thats the case it points to high CPU causing issue which is difficult to solve

[Temilit]

Will link youtube with only sound.

The test you're about to watch was conducted as follows:

First test in mirage cokpit 3 players (1 listener who was recording) and me counting on vhf (first counter) once i get to 4-5 somewhere second player starts transmitting on UHF counting in the same manner. Second test was conducted in the same manner except we were all in spectator using the overlay.

No spike in cpu use was detected.

You can clearly hear the distortions as we were counting over eachother and it completely dissapears once first counter is done. https://youtu.be/QFloX438vzo

[ciribob]

Perfect! Thank you very much.

Its good the CPU spike is discounted.... That would need a much more serious rewrite if that was the case.

What was average CPU during the test? 80% or something like that? High but not at 99%?

[Temilit]

Full discolsure i only checked the cpu while i was in spectator mode (no difference in distortions) and i could not see any noticable increase (usually the cpu stans around 45-50% in spectator)

If you want a more detailed analysis of the cpu we need to make a new test since we did not take any detailed data on cpu usage.

I can however say that everyone at masterarms has experienced this issue during operations when we've used this plugin. And btw great work with the program, mostly works great

[ciribob]

Sorry for the trouble!

As a first test you can do yourself:

could you just edit this line:

https://github.com/ciribob/DCS-SimpleRadioStandalone/blob/master/Scripts/DCS-SRSGameGUI.lua#L8

and change to false

and

https://github.com/ciribob/DCS-SimpleRadioStandalone/blob/master/Scripts/DCS-SimpleRadioStandalone.lua#L21

and change to false

Then start a single player mission, jump in an aircraft , start 3 radios & connect to a server on all 3 and then try transmitting.

You should hear yourself 3 times over without distortion (hopefully) assuming all 3 radios are tuned to the same frequency.

This should prove that its not a mixing issue or some other hardware issue which'll help me narrow it down.

Second Test:

Log cpu + ram usage while 2 people transmit on the same frequency to a third user and see if you get distortion

Third Test:

Log cpu + ram usage while 2 people transmit on different frequencies to another user tuned into both frequencies

It's a big ask but would be extremely helpful, nothing obvious in the code still that explains why

[Temilit]

I will get to this as soon as possible, been a bit busy. Hopefully tonight

[evilivan]

Several of us in the 229th are also experiencing this problem. I can see you have testing underway with Temilit, but if there is anything we can do to expedite the fix let us know...

Thanks - otherwise a great bit of software! Just need it to work with multiple radios ;-)

[ciribob]

If you could replicate the tests listed above, that would be great!

[sniporbob]

Hey Ciribob, just chiming in to say that I've got the same issue. Here's a short section of recording from Blue Flag:

https://www.twitch.tv/sniporbob/v/100796460

I don't have two other people to try out tests 2 and 3, but for test 1 when you say to start three radios do you mean three instances of SRS?

EDIT: Played around with Audacity and Temilit's recording. https://www.youtube.com/watch?v=-2HMlJN97O4 EDIT2: The 8 to 9 Hz thing happened in my game recording too, even when it was just the noise of the UH-1H.

[ciribob]

Thanks for the recordings!

@sniporbob Yes just start 3 instances of the radio for test one. They should all work fine as long as you've made the changes to the lua listed above

[sniporbob]

Test 1 was successful. After sorting out the hotkey issue (otherwise they all transmit lol) I heard 2 instances of myself. The radio effect seemed to be working normally and there was no distortion like what I had been experiencing with 2 separate players talking at once.

EDIT: with regards to tests 2 and 3, I hear distortion in both cases. I hear it on Blue Flag whenever two people talk at the same time. Since it's sort of up to chance whether or not this happens I can't really log the CPU and RAM. Hopefully someone will be able to give you the other test results that I can't complete on my own.

[ciribob]

@sniporbob thanks for doing the first test. It at least shows that the audio mixing / audio pipeline isn't obviously at fault. Unfortunately that makes it pretty hard to work out why it doesnt work for an external transmission...

[sniporbob]

Two more recordings for you, but no cpu or ram logs to go along. Sorry :(

The audio was set up with 30FM on the left ear and 264UHF on the right ear. 124VHF was set to both ears but nobody was using that channel.

This clip shows that the distortion happens when hearing people talk simultaneously on separate channels and separate ears: https://www.twitch.tv/sniporbob/v/101312922

This clip shows that the distortion happens when hearing people talk simultaneously on the same channel: https://www.twitch.tv/sniporbob/v/101313688

I think there is something wrong with the mixing. If you record the audio in audacity you can see how receiving something in one ear affects the sounds of the aircraft in the other ear.

[ciribob]

Yeah I keep coming back to the mixing but if you do test 1 and jump in fc3, transmit on different radios covering left and right ear, it works fine...!

Which is highly confusing as if the mixing is at fault, it should fail then.

I'll keep looking, thanks for the recordings :)

Might try building my own mixer again.... Will increase latency by a bit but good for a test

[ciribob]

Still on this, I have an idea i'm going to try on the weekend

[ciribob]

I've narrowed it down to only one part of code it could be in the naudio library. will try something soon with that

[sniporbob]

Awesome! I'm really excited that you may have figured it out, It'll be a massive improvement (for me at least).

Also (and this may not be helpful anymore) I encountered another odd situation that I forgot to make a comment about. Someone accidentally keyed up on both UHF and FM and transmitted simultaneously on both radios. My aircraft was tuned to both frequencies, and I heard the distortion. I didn't happen to be recording at that time though.

[ciribob]

Bad news, still can't replicate and changing that part of the library doesnt look like it'll make a difference.

Going to have to look at porting the audio part to C++

[birgersp]

@ciribob You've probably heard about it before, but QT will make this incredibly easy for you. It's free as long as you keep it open source.

[ciribob]

i'll think i'll start small with just using a small bridge of Managed / visual C++ to native non .net C++ and see how I get on. I'd rather not use QT as its a massive learning curve in its own right as its a pretty extensive framework? I'll take a proper look though at it again as I last looked at it when trying to make a native app for Symbian...

[fdsprod]

@ciribob I'll admit I've only looked at the code for ~30 minutes, but do you think this could accomplish a fix for the issue here? http://mark-dot-net.blogspot.com/2012/01/handling-multi-channel-audio-in-naudio.html. Seems to at least be related,

[ciribob]

oddly the data is already multiplexed. :/ the data is merged down via the audio mixer but either GC or CPU pressure causes the mix to be delayed and the weird sound effect (I think)

If I run local instances of the radio multiple times it all merges ok... Sorry still no access to dev pc so not managed to work on this in a while.

[fdsprod]

Sounds more like a latency issue then, because I hear this just about every time 2 or more people talk, doesn't matter what I'm doing (heavy cpu/gpu or not).

I'll look at the code again, does that audio stream itself have timestamp information? Ill keep looking, would really love to help solve this issue.

I am a software engineer by trade, but all my proficiency is in UI/Client engineering, never messed with sound, so I my questions or input has no merit, this is why ;)

[ciribob]

no worries, any help with it would be massively appreciated! :)

If you try the test above: https://github.com/ciribob/DCS-SimpleRadioStandalone/issues/148#issuecomment-258715155 then you can see it'll mix correctly locally.

With the latency, there isn't timestamp information per se but each packet has and ID thats unique per client, so you can log the time differences here for processing (but remember, the logging to the console will also cause a minor impact to speed as well)

https://github.com/ciribob/DCS-SimpleRadioStandalone/blob/master/DCS-SR-Client/Audio/JitterBufferProvider.cs

This ^ is where the audio is added, there is one of these for each client. The read method is called by the OS via the NAudio library when the sound buffer is ready for more data. The reads for multiple Jitter buffers are merged by an NAudio MixingSampleProvider (https://github.com/ciribob/DCS-SimpleRadioStandalone/blob/master/DCS-SR-Client/Audio/AudioManager.cs#L166)

If you follow through the audio, its a bit convoluted (needs a refactor) but not too bad and you dont have to worry too much about how it works, just know that there are some bytes headed to a queue is enough 👍

[fdsprod]

@ciribob Been looking at this a bit, I kinda think this is netcode related. I still need to verify my thoughts but listening to audio of the issue, it feels like the silence code in JitterAudioProvider is getting stuffed in and the interleavee between the 2 radios is due to packets coming in, in an alternating fashion, and then silience being stuffed in between each packet. Again, this is only what it sounds like to me, and only because its so consistant. Have you considered using TCP over UDP to ensure you get proper packet sequencing? Also what if you were to buffer some of the client audio before playing it? This would ensure you have less silence due to latency or a network hickup. Just some thoughts, gonna keep looking and do some real testing soon (life getting in the way as I'm sure you understand) :)

[ciribob]

That is possible, and its something I thought i tested but maybe it needs another go through, good sport!

What i do is for the first new audio packet thats received (or if one hasn't been received for 180 ms) I append another 100 ms onto the front of the packet

This in effect functions as the "buffer" of client audio as the buffer is primed and starts being consumed in 20 ms chunks, with the already send client audio following on and then subsequent audio added to the end.

https://github.com/ciribob/DCS-SimpleRadioStandalone/blob/master/DCS-SR-Client/Audio/ClientAudioProvider.cs#L62

A simple test i guess would be to just increase the amount of silence added to the start of the first new voice packet?

Haven't tried TCP with the audio but assumed that the jitter from TCP (due to retry window) would make it worse. Its also more load for the server (not much as the network card + os should take their share) Definitely worth a try! Thanks 👍

If you can crack this it would be an incredible help.

[fdsprod]

Ya i was going to test exactly that if i got a chance (increase the silence), As for Jitter over TCP, ya not sure, but lets be honest, at most 50 clients sending audio over TCP, probably not a huge issue. But ya maybe tackle the obvious and easiest first, I will try the silence thing when i get time (literally just had a new baby 3 weeks ago... my free time went down the drain lol)

[ciribob]

Congratulations! This is definitely second place for a long time then for good reasons 👍

[476th-Scaley]

Hi all, thanks for the work on this issue. Just posting another sample test with setup notes if you need more data. Happy to get some 476th guys to do mass tests if you think you have a working solution or need more data.

Test setup notes in the youtube description

https://youtu.be/9rhXCu0gCX0

[Gliptal]

Heh gotta love the music I was playing.

[ciribob]

Please test the latest alpha release if you can. If it's noticeably better then I'll do a release this weekend! :)

[132nd-Entropy]

@ciribob we tested it again and it seems to be better than before. For our normal operations we usually have all 3 radios active with internal comms, awacs and JTAC all babbling at the same time so Im not sure if this would be good enough to understand 9lines with coordinates etc, but it seems to be better than the video Scaley linked on Feb 27? here is a link to the video that my sqdmate recorded, be advised this was no mass test, just 3 people (2 talking one recording and listening)

https://www.youtube.com/watch?v=KxI9dBUT0_Q&feature=youtu.be

[fdsprod]

@ciribob what did you end up changing? I dont see any commits tagged to the issue.

[ciribob]

@132nd-Entropy Yes that seems much better than before. Both are pretty readable and im not sure if you mixed the two original voices together in an audio program if it would sound much different. The weird phase effect seems to be gone at least!

@jeffboulanger The fix was literally changing the WASAPI read time from the buffer from ~ 140 to 40 ms. Going to try lower again but will do an intermediate release first

[fdsprod]

@ciribob ah nice, easy fixes are the best fixes ;)

[ciribob]

@jeffboulanger Yeah dont know why i didn't try it before! Oh well..

[ciribob]

going to close this now due to this feedback: https://forums.eagle.ru/showpost.php?p=3096512&postcount=1384

Thanks for all your help!