July 24, 2008 12:12pm pdt

1. grblades 121,843
2. rpalmeira22 54,500
3. bfason 41,278
4. lrmoore 30,270
5. feptias 25,400
6. Joel_Sisko 24,200
7. jdechiaro 22,100
8. KlBe 14,000
9. michofreiha 12,625
10. DrDamnit 12,064
11. decoleur 10,700
12. cstosgale 9,375
13. shepimport 6,750
14. xuserx2... 5,850
15. from_exp 5,750

1. grblades 615,764
2. Joel_Sisko 201,419
3. rpalmeira22 176,713
4. kode99 81,007
5. lrmoore 73,728
6. feptias 63,332
7. bfason 61,328
8. KerryG 40,690
9. scampgb 40,637
10. jfrady 36,354
11. benhanson 34,678
12. harbor235 28,866
13. RobWill 24,057
14. shepimport 23,973
15. jdechiaro 22,100

10.12.2006 at 04:23AM PDT, ID: 22021857

	[x] Attachment Details

[x]

The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

The Grade of the Solution
The Zone Rank of the Expert Providing the Solution
The Number of Author and Expert Comments
The Number of Experts Contributing
The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

9.0

Audio streaming TCP/IP TCP_NO_DELAY ACK Delphi / Droopy Eyes / Indy 10.0 GSM CODEC 6.10 PACKET DELAY SCRAMBLED AUDIO

Zone: Voice Over IP

Tags: delphi, audio, streaming

Hi all experts,

First I'll try to explain what our software is doing and then I'll give a description of the problem.

We have three applications :
- one application is reading analog audio from the audio card and converts it to an audio stream using the GSM 6.10 CODEC. The delphi component used for doing this is droopy eyes. After the conversion to the stream is done, the application sends this stream out to another application using UDP
- the second application receives the stream and sends it out via TCP/IP to a number of connected clients. No audio components are used here, only the Indy 9.0 Delphi components for read the multicast and send it out over TCP/IP. This application is in fact the TCP server.
- the third application (client application) receives the audio signal via a TCP/IP client and delivers the stream packet to the Droopy Eyes component who convert the stream back to analog audio.

As you al may know, TCP/IP is an ACK/NACK protocol causing one packet to be send, an ACK send from the client application and then sending the next packet. So, TCP/IP always waits for sending a new packet untill an ACK is received from the previous sent packet.
There is an option in the TCP layer TCP_NO_DELAY which allows tcp/ip to not waiting an ACK before sending the next packet.
It is necessary to set this option because the packets need to go out fluently to have a good steady audio connection.

Now following problems occur :
- sometimes a client with a bad connection did not ack the last x (can be 25 for example) packets yet causing the TCP server to halt and wait untill he receives ACKs again. This causes all clients to not have an audio signal for some time since the TCP server is completeley blocking
- Sometimes the audio signal is scrambled and it is not clear in any way anymore. This seems to be because several packets are stuck together causing the Droopy Eyes buffer to generate a too big load and not processing the packet.

My questions :

- is there any way that we can infuence TCP/IP to not wait on the ACKs so our server application is not blocking
- can we set an option so packets are NEVER stuck together
- and off course any advice on any level is welcome

Start your free trial to view this solution

Question Stats

Zone: Networking

Question Asked By: TDDatATS

Solution Provided By: grblades

Participating Experts: 1

Solution Grade: B

Translate:

Loading Advertisement...

20080236-EE-VQP-29