.Net Audio Issue on Live Stream

[trooper]

Hello,

Im really fresh to SFML, so first I want to say thanks for such a great Project.
Actually, Im implementing a Live Voice-Chat over the Internet(with SFML.Net) and already got it working.

When the Voice-Packet is send over the Network, it will be handled by the server which returns it with some more informations. On Client Side I extract these informations and call a Sound-Playing-Function with the voice samples as a byte array(for networking).
Well the packets coming in right here are in a really short intervall (100ms)

this code handles the packets and playing them:

private void PlayAudioData(byte[] data, float[] myposition, float[] mydirection, float[] talkerposition, bool self)
        {
            //set my position
            Listener.Position = new Vector3f(myposition[0], myposition[1],myposition[2]);
            //rotation not implemented in protocol right now
            Listener.Direction = new Vector3f(mydirection[0], mydirection[1], mydirection[2]);
            //if i muted the speaker then dont play
            if (outMuted)
                return;
            //convert audio data back to short
            short[] sdata = new short[(int)Math.Ceiling((double)data.Length / 2)];
            Buffer.BlockCopy(data, 0, sdata, 0, data.Length);
            //load into the buffer
            buffer = new SoundBuffer(sdata, 1, this.SampleRate);
            sound = new Sound(buffer);
           
            //set speakers position
            if(self)
                sound.Position = new Vector3f(talkerposition[0]+1, talkerposition[1]+1, talkerposition[2]+1);
            else
                sound.Position = new Vector3f(talkerposition[0], talkerposition[1], talkerposition[2]);
            sound.RelativeToListener = false;
            sound.MinDistance = 1f;
            //loudness regulation, lower value = louder sound from distance
            sound.Attenuation = 4;
            sound.Play();
        }

the Problem is, that after each Sound.Play, a short clicking sound appears (like abrupt voice-stopping).
With 100ms packets right here, this disturbing sound appears 10 times a second.

Is there a way to solve this problem?

thanks
trooper

[eXpl0it3r]

Do you use a client side replay buffer? Meaning, are you playing the sound snippet you get immediately back or are you collecting a certain amount of audio data before sending it to the audio card?

If an audio signal is interrupted like at the end of the image below, the "high" point, needs to be drawn back to 0 in an instant which from my experience can cause clicks.



I have no idea how you're implementing the voice chat, but it's not exactly trivial and if you want it to be performant, you'll have to look into good voice compression algorithms and I certainly hope you're running over UDP already.

[trooper]

Hi eXpl0it3er,

Thanks for your time and help.

I've tried both, buffering and immediately playing it back. The buffering just moves the "Click"-Sound to the end of the buffer. With that in mind, the problem is just a bit better, but for sure costs delay-time.
So even if I buffer a whole Second, I will hear the Sound each Second and loose a lot of realtime speed.

In generel I've implemented a Buffer for checking and merging splitted packets together and removing the "jitter". So I think the Networking-Part is just fine. I got a really good performance and clear voice, except of these "Clicks".

The Problem you described(draw the audio signal back to 0 at the end) will be definetly my problem.
Do you have any idea how I can avoid that?

The only thing coming to my mind is to buffer as long as there is a signal near to 0, splitting it there, playing just the left part and buffer the right part to the next packet.

this may work. So, What do you think?

Thanks again, even if we dont find a solution for that, you already helped me alot.

best regards
trooper

[eXpl0it3r]

I'm not sure how your implementation really works, but for continuing stream of audio, you want to implement your voice "receiver" as sound stream, so you'll not end up with x buffers of randomly sliced audio bits, but you simply fill a short local buffer and keep streaming the audio from that.
Additionally, if you know you don't get the next audio packet in time before the buffer gets played, you may want to use some simple algorithm to gracefully pull back the audio signal to zero.