我目前正在使用DirectSound开发应用程序，以便在Intranet上进行通信。 我有使用UDP的工作解决方案，但后来我的老板告诉我他想出于某种原因使用TCP / IP。 我尝试以与UDP几乎相同的方式实现它，但收效甚微。 我得到的基本上只是噪音。 其中20％是录制的声音，其余的只是奇怪的噪音。
我猜的原因是TCP需要多次读取所有接受的数据，直到它能够播放我能播放的最终声音。
现在有两个问题：
不，使用TCP是一个糟糕的主意。 在这种情况下UDP将执行得更好，丢弃/不同步数据包无关紧要！
如果您的老板无法理解技术细节，请告诉他或她几乎所有当前存在的VOIP系统都使用UDP并且必须有一个原因：Skype，ventrilo，teamspeak，魔兽世界等等
TCP 不应该引入任何噪声。 抖动和滞后，是的（特别是如果你的链接有损）; 但根本没有噪音。 你的编程有点可疑。
顺便说一句，我同意UDP在这种情况下比TCP更合适。
大多数语音应用程序是使用RTP协议构建的，该协议是通过UDP端口的流。 其中大多数都支持编解码器，以确保在从一端流到另一端之前压缩媒体。 与您的老板讨论带宽要求。
我很确定大多数流式音频/视频使用UDP ...你可能会丢失一些数据包，但你永远不会注意到。
如果你收到了噪音，你可能会超出已经成功填充数据包并播放空/未初始化缓冲区的缓冲区部分。
TCP比UDP慢多少？ 使用TCP，如果任何数据包无序到达或损坏，您将获得重新传输延迟。 我会说有很多方法可以优化TCP，因此延迟更少。 在Linux和Winsock中都有一个TCP_NODELAY选项可供使用。 此外，紧凑的编解码器将有助于G.729保持有效载荷大小。 由于传输是基于正在接收的分组（按顺序 - TCP），因此应该集中精力优化分组大小，使其足够小以减少重传延迟，但又要足够大以维持高质量的流。 一个好的TCP voip程序将能够在运行中改变编码质量和数据包大小，而发送方必须向接收方发出变化信号。 但实际上使用TCP实时的唯一优势是它不太可能被防火墙阻止。
为了正确回答这个问题，我觉得需要解释VoIP的一些关键概念。
首先，UDP是最流行和广泛使用的VoIP方法。 请记住，IP网络是分组交换的，非理想的非实时数据通信，不适用于实时VoIP。
为了克服这个问题，使用了UDP。 UDP是不可靠和无连接的协议。 虽然UDP会丢失数据包，但仍然可以理解语音音频，大脑将有效地补偿错误。 这就是为什么你仍然可以通过带有3条信号的手机与某人交谈。
数据包丢失和突发长度
数据包丢失通常是由于拥塞而发生的，因此数据包丢失的数量将取决于网络配置的程度。 使用UDP的VoIP中的数据包丢失通常以突发长度发生。 突发长度是传输中连续丢失的数据包的数量，因此突发长度为3表示连续3个数据包丢失。
丢包补偿
在发生分组丢失的情况下，简单的分组丢失补偿技术将会出现问题，并且服务质量将不会受到严重影响，即使在20-30％的分组丢失的情况下，仍然可以理解语音。 方法包括：
重复上次成功接收的数据包。
填写 - 在差距中保持沉默。
拼接 - 实际上可以考虑通过将间隙的开始和结束推到一起来消除由突发长度引起的间隙。
减小突发长度大小的好方法称为交织，因此增加QoS是交织 。 块交织功能接收语音并将其分成一组数据包。 这些数据包被加载到一个矩阵形状的缓冲区（例如4乘4），一个函数用于旋转或转置缓冲区，因此数据包不是有序的。 在接收方，该功能的反转用于重新排序分组。 这种方法简单有效，见下图：
alt text http://img688.imageshack.us/img688/3962/capturevnk.png
我最近创建了一个小型VoIP应用程序。 通过使用UDP的无线LAN。 我不确定您的应用程序的确切要求，但通常VoIP应用程序（两个主机之间）可以实现如下：
alt text http://img338.imageshack.us/img338/6566/captureec.png
在图中，应用程序定义了它自己的数据包设计。 标题可以是数据包编号（使用1个字节），有效负载是音频数据（n个字节，有效负载大小）。 定义这种方法可以实现更好的数据包补偿技术，并允许编程的逻辑流程。
由于多种原因，TCP是VoIP的不良选择 。 快速谷歌的“TCP VoIP”揭示了支持这种观点的第一个结果。
TCP是一种可靠的，连接方向的协议，这意味着在传输中丢失的数据包在某些时候将从另一个主机重新发送。 这种重传对于实时服务是不切实际的，并且会增加抖动，延迟并且可能增加分组丢失（在某些情况下）。
你的问题的答案
我得到的基本上只是噪音。 其中20％是录制的声音，其余的只是奇怪的噪音。
TCP不应该引入噪声，它应该引入抖动和延迟。 套接字往往具有自动定义的超时时间，您是否定义了超时时间？ 如果没有，为什么在播放前没有及时收到正确的数据包？
我在正确的轨道上吗？ 将TCP / IP用于此类应用（各种语音会议）是否是个好主意？
不， 不使用TCP / IP这不是一个好主意。 您的经理似乎错误地认为任何数据包丢失都是一件可怕的事情。
摘要
这里已经展示了一些通用的关键概念，以尽可能地帮助解决这个特定问题，但是这不应该被认为是详尽无遗的。 确保VoIP系统还使用语音编码/信号处理技术的一些基本原理。
要记住的关键点是：
使用UDP进行VoIP。
实现丢包补偿
技术。
块交织器很简单
提高QoS的有效方法。
我希望这有帮助。
当人们谈论TCP / IP堆栈时，它们通常意味着“整个互联网协议栈”，其中包括UDP。 也许这会让你的经理高兴;-)
TCP / IP可以工作; 它将提供数据。 如果您不担心数据包丢失，它可能不如UDP那么高效，但您应该能够很好地传输数据。
现代路由器和网络上的TCP / IP速度非常快。 它不仅能够处理IP语音通信。 （我自己做过）
我的猜测是你的实现有一些与缓冲区大小有关的错误。
没有理由你应该通过TCP获得噪音，因此它看起来像你的代码中的错误。 事实上，我们收到的大多数流媒体（想想YouTube）都是通过TCP完成的。
TCP的问题是抖动。 数据流的传送将被延迟，直到收到并重新排序所有数据包。 现在，因为多媒体的延迟交付与完全没有交付一样好。 这通常是比简单插入缺失帧更差的选择。 如上所述，如果数据包丢失最小并且您的网络速度很快，则应该没有区别。
UDP上的RTP / RTCP通常用于传送媒体流。 RTP包括诸如包头中的序列号之类的内容，其允许在可能的情况下将延迟包插入其正确位置。 RTCP具有报告功能，允许编解码器适应数据包丢失开始变高的情况。 因此，RTP / RTCP提供一些但不是所有TCP功能。
对于TCP上的流媒体，可以通过使用大抖动缓冲区轻松解决这个问题。 这增加了延迟，但对于单向流，这不是问题。 然而，延迟是双向对话流中的主要问题。
但是，TCP的一个主要优点是它比UDP更容易遍历防火墙。 建立一个TCP会话，防火墙打开以发送和接收数据。 这对于UDP来说更复杂，尤其是当人们期待传入的数据流时。 有一些方法可以解决这个问题，但它们可能很复杂，可能涉及了解会话控制协议（如SIP或RTSP）。
我已经开发了一种语音操作ip解决方案，用于与wave-api进行双工通信，用于远程控制业余无线电收发器。 它与UDP以及TCI / IP一起运行良好！ 我每64 ms使用512字节缓冲，8kHz单声道波数据。 我在美国和欧罗巴之间的最后一个月工作了很好的TCP / IP！ 现在我的问题是：wave-api与Win7无法正常工作，因此我认为DirectSound是更好的方法。 我刚刚在Managed DirectX9下实现了我的应用程序，我的应用程序是VB.Net 2008.我使用DirectSound搜索流媒体输出的文档链接 - 用于VB.Net的ManagedDirectX9。
实时流数据使用UDP有几个主要原因。 其中最大的一个是接收延迟数据，就像根本没有接收数据一样好，并且延迟流重传肯定不是一个好主意。 对于VoIP，您的延迟容限大约为150毫秒。 任何延迟时间超过的语音数据包对用户来说都会变得明显。
至于你为什么会受到噪音的影响，你如何处理因重传而迟到的数据包？
取决于底层网络的类型，如果你的可靠性为99.9％的以太网，我的猜测是TCP会做得很好。 但是，如果你这样做，那么说802.11就不是那么好了。
您可以向您的老板询问使用TCP的特定原因，然后实施该特定服务，例如基本可靠性或UDP上的纠错服务。 您可能还想研究一下RTP。（ http://en.wikipedia.org/wiki/Real-time_Transport_Protocol ）
