TCP delay

[aman_bajra]

I have a voip program in which one VI acts as server and other acts as client. Server is listening at two port. At one port , it sends audio data to client and in another port it receives data then plays it. I am using TCP. My question is, is there any difference or time delay when in TCP , a listener writes data insteand of receiving. Does it cause any delay. I have included two sets of files

Set 1 - A_speaker and A_microphone

Set 2 - B_speaker and B_microphone

In Set 1 listener (server) receives data (sound data from TCP read ) and in Set 2 listener sends data (it acumulates wave data from microphone and then sends to TCP write). I could feel some delay in second case which is not good for a VOIP type program.

Is it that in TCP, listener recieves data faster than sending ?

[Jennifer_R]

Hi aman_bajra,

I'm not aware of any difference in timing between sending and receiving data.  You may be interested in the thread here which discusses optimizing TCP/IP communication.   

[altenbach]

First of all, for some reason you still use the legacy sound tools. SInce you are using LabVIEW 8.5, you should use the new and improved tools from the sound palette.

I have no idea what the purpose of your outer case structures is. Can you explain?

You probably should also rearrange a few things. Let's look at the "speaker" program for example:

• AFAIK, The SO start does not need to be in the loop, because you never call SO stop.
• The "SO wait" should be before the "SO write", this way it can receive new data at the same time it is playing the old one. In your case, the TCP read cannot start until the entire iteration is finished because "SO wait" blocks the loop. If you place it before the write, the loop can spin and it will receive new data while it is waiting for the sound to finish.
• I don't think you need the 5ms wait, because the loop rate is determined by the sound duration and tcp arrival.
• You should probably stop the loop if there is an error.
• Similar problems in the SI VIs (microphone).
• That 1000ms wait in the microphone VIs has no meaning, because it will not delay anything since there is no data dependency. Why is it there? It will run in parallel to the while loop and both start at the same time.
• These are just some casual observations. I haven't studied things in detail.
• ...

Maybe you can rearrange stuff a bit and see if things improve. 🙂

[aman_bajra]

Sorry for the delayed reply. I was trying to change the audio VIs to new ones. I have done the changes but I am facing one problem . Every time I run the program it gives one error that says  LabVIEW:  (Hex 0x12D7) A task must be running to perform this operation. I have attached the pic of VI herewith.  It is coming from Sound Input Read. Could you hint me on what does the error mean?

[Jennifer_R]

Hi aman_bajra,

I have heard of that error occurring when using the Sound Input Read VI with TCP if the input buffer is full.  I would suggest trying various combinations of values for the sample rate and the number of samples / channel.  A post about a similar situation, and the values that worked in that case, can be found here. 

[aman_bajra]

Hi altenbach,
Thanks for your suggestions. Actually when I started this work, I found some problem with the new audio tool that is why i opted for the older one but might be I couldnt program it well. Here I have attached a program using the new audio tools. The problem is that I find reverberation in it which is not present using the old audio tools. Can you see through the program and let me know where I am going wrong.
Thanks

[Jennifer_R]

Hi aman_bajra,

You may want to try one of the LabVIEW example programs to test if there is reverberation with that code as well.  I would suggest looking at the Simultaneous Sound IO VI, which can be found in LabVIEW under Help » Find Examples » Hardware Input and Output » Sound.