我目前正在使用DirectSound开发应用程序，以便在Intranet上进行通信。我有使用UDP的工作解决方案，但后来我的老板告诉我他想出于某种原因使用TCP / IP。我尝试以与UDP几乎相同的方式实现它，但收效甚微。我得到的基本上只是噪音。其中20％是录制的声音，剩下的只是奇怪的声音。
我的猜测是因为TCP需要多次读取所有接受的数据，直到它能够播放我可以播放的最终声音。
现在有两个问题：
答案 0 :(得分：14)
不，使用TCP是一个可怕的想法。在这种情况下，UDP会表现得更好，丢弃/不同步数据包也无关紧要！
如果您的老板无法理解技术细节，请告诉他或她几乎所有现有的VOIP系统都使用UDP并且必须有一个原因：Skype，ventrilo，teampeak，魔兽世界等等
答案 1 :(得分：7)
为了正确回答这个问题，我觉得需要解释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个字节，有效负载大小）。定义它可以实现更好的数据包补偿技术，并允许编程的逻辑流程。
出于多种原因，对于VoIP来说，TCP是一个糟糕的选择。快速谷歌的“TCP VoIP”揭示了为什么第一个结果支持这个view。TCP是一种可靠的，连接方向的协议，这意味着在传输中丢失的数据包将在某一时刻从其他主机重新发送。这种重传对于实时服务来说是不切实际的，并且会增加抖动，延迟并可能增加数据包丢失（在某些情况下）。
您的问题的答案
我得到的基本上只是噪音。其中20％是录制的声音，其余的只是奇怪的声音。
TCP不应该引入噪声，它应该引入抖动和延迟。 套接字往往具有自动定义的超时时间，您是否定义了超时时间？如果没有，为什么在播放前没有及时收到正确的数据包呢？
我在正确的轨道上吗？将TCP / IP用于此类应用（各种语音会议）是否也是个好主意？
不不使用TCP / IP这不是一个好主意。您的经理似乎错误地认为任何数据包丢失都是一件可怕的事情。
<强>摘要
这里已经展示了一些一般性的关键概念，试图尽可能地帮助解决这个特定问题，但这不应该被认为是详尽无遗的。确保VoIP系统还使用语音编码/信号处理技术的一些基本原理。
要记住的关键点是：
使用UDP进行VoIP。
实施丢包补偿 技术。
块交织器是简单的和 提高QoS的有效方法。
我希望这会有所帮助。
答案 2 :(得分：3)
当人们谈论TCP / IP堆栈时，他们通常意味着“整个互联网协议栈”，其中包括UDP。也许这会让你的经理感到高兴; - ）
答案 3 :(得分：1)
答案 4 :(得分：1)
现代路由器和网络上的TCP / IP速度非常快。它不仅能够处理IP语音通信。 （我自己做过）
我的猜测是你的实现中有一些与缓冲区大小相关的错误。
答案 5 :(得分：1)
没有理由为什么你应该通过TCP获取噪音，因此它看起来像你的代码中的错误。事实上，我们收到的大多数流媒体（想想YouTube）都是通过TCP完成的。
TCP的问题是抖动。数据流的传送将被延迟，直到收到并重新排序所有数据包。现在，因为多媒体的延迟交付与完全没有交付一样好。这通常是比简单插入缺失帧更差的选择。如上所述，如果数据包丢失很小并且您的网络速度很快，则应该没有区别。
UDP上的RTP / RTCP通常用于传送媒体流。 RTP包括诸如包头中的序列号之类的内容，其允许在可能的情况下将延迟包插入其正确位置。 RTCP具有报告功能，允许编解码器适应数据包丢失开始变高的情况。因此，RTP / RTCP提供了一些但不是所有的TCP功能。
对于TCP上的流媒体，可以通过使用大抖动缓冲区轻松解决这个问题。这增加了延迟，但对于单向流，这不是问题。然而，延迟是双向对话流媒体中的主要问题。
但TCP的一个主要优点是它比UDP更容易遍历防火墙。建立一个TCP会话，防火墙打开以发送和接收数据。这对于UDP来说更复杂，尤其是当人们期待传入的数据流时。有很多方法，但它们可能很复杂，可能涉及了解会话控制协议（如SIP或RTSP）。
答案 6 :(得分：1)
我已经开发了一种语音操作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。
答案 7 :(得分：0)
直播数据使用UDP有几个主要原因。其中最大的一个是接收延迟数据，就像根本没有接收数据一样好，并且延迟流重传肯定不是一个好主意。对于VoIP，您的延迟容限大约为150毫秒。任何延迟时间超过的语音数据包对用户来说都会变得明显。
至于你为什么会受到噪音的影响，你是如何处理由于重传而迟到的数据包？
答案 8 :(得分：0)
取决于底层网络的类型，如果你的可靠性为99.9％的以太网，我的猜测就是TCP会做得很好。但是，如果你在802.11上做这件事，那么TCP就不是一个好主意了。
您可以向您的老板询问使用TCP的特定原因，然后实施该特定服务，例如基本可靠性或UDP上的纠错服务。您可能还想查看RTP。（http://en.wikipedia.org/wiki/Real-time_Transport_Protocol）
答案 9 :(得分：0)
TCP 不引入任何噪音。抖动和滞后，是的（特别是如果你的链接有损）;但根本没有噪音。你的编程很可疑。
BTW，我同意在这种情况下UDP比TCP更合适。
答案 10 :(得分：0)
大多数语音应用程序都是使用RTP协议构建的，该协议是通过UDP端口传输的。其中大多数都支持编解码器，以确保在从一端流到另一端之前压缩媒体。 与您的老板讨论带宽要求。
答案 11 :(得分：0)
我很确定大多数流媒体音频/视频都使用UDP ...你可能会丢失一些数据包，但你永远不会注意到。
答案 12 :(得分：0)
如果你收到了噪音，你可能会超越已经成功填充数据包并播放空/未初始化缓冲区的缓冲区部分。
答案 13 :(得分：0)
TCP比UDP慢多少？使用TCP，如果任何数据包无序到达或损坏，您将获得重新传输延迟。我会说有很多方法可以优化TCP，因此延迟更少。在Linux和Winsock中都有一个TCP_NODELAY选项可供使用。此外，紧凑的编解码器将有助于G.729保持有效载荷大小。由于传输是基于正在接收的分组（按顺序 - TCP），因此应该集中精力优化分组大小，使其足够小以减少重传延迟，但又要足够大以维持高质量的流。一个好的TCP voip程序将能够在运行中改变编码质量和数据包大小，而发送方必须向接收方发出变化信号。但实际上，实时使用TCP的唯一优势是它不太可能被防火墙阻止。
