完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
我已经建立了一个客户机/服务器板来发送音频从一个建筑物到另一个建筑。音频传输每天大约20-25次。它用于发送语音页面到远程大楼中的扬声器。它已经使用了几个星期,效果很好。基本上,我所做的就是向远程建筑传输UDP。远程建筑是服务器,传输来自主楼的客户端,主楼的原始音频通过PIC上的ADC输入转换成数字信号。我的转换率是8千赫和音频听起来不错。数字信号在PIC上发送USAT(230400 BPS),并通过USRIO数据UR—K2模块转换为以太网。在远端,URR K2将以太网信号转换回PICUSAT接收到的RS232,并落到PIC DAC上。DAC的输出驱动一个放大器来驱动扬声器的放大器。我正在考虑设置一些东西来处理一个以上的远程建筑。例如,可能有三个需要被分页的远程建筑。我可以在主楼和每个远程建筑的服务器上安装三个客户。这是可行的,但是使用三个客户端意味着三个单独的硬件。这是最简单的答案吗?或者有一种方式,音频可以发送到三个不同的服务器在同一时间?我唯一能想到的解决方案是在主建筑上拥有服务器,在偏远建筑上拥有客户。如果我这样做的话,假设我必须从UDP转换到TCP,保持生存状态,这是正确的吗?我现有的硬件使用PIC16F1718来驱动UsRIO模块。我正在考虑删除UsRIO模块,并用PIC32做所有的事情。PIC32也会给我更多的RAM来缓冲链接两端的音频。
以上来自于百度翻译 以下为原文 I have built a client/server pair of boards to send audio from one building to another building. The audio transmissions occur about 20-25 times per day. It is used for sending a voice page to overhead speakers in the remote building. It has been in use for several weeks and it works fine. Basically all I am doing is an UDP transmission to the remote building. The remote building is the server and the transmission comes from the client at the main building. The originating audio at the main building is converted to a digital signal using an ADC input on the PIC. My conversion rate is 8 KHz and the audio sounds good. The digital signal is sent out the USART (230400 bps) on the PIC and is converted to Ethernet by a USRIO Data USR-K2 module. At the remote end, the USR-K2 converts the Ethernet signal back to RS232 which the PIC USART receives and drops onto the PIC DAC. The output from the DAC drives an opamp which drives the amplifier for the speakers. I am thinking about setting something up to handle more than one remote building. For instance, there could be three remote buildings that would need to be paged. I could setup three clients at the main building and a server at each of the remote buildings. This would work but using three clients means three separate pieces of hardware. Would this be the easiest answer? Or is there a way that the audio could be sent to three different servers at one time? The only solution I have been able to think of is the have the server at the main building and clients at the remote buildings. Am I correct in assuming that I would have to change from UDP to TCP with keep alive running if I do this? My existing hardware uses a PIC16F1718 to drive the USRIO modules. I am considering eliminating the USRIO modules and doing everything with a PIC32. The PIC32 would also give me more RAM for buffering the audio at each end of the link. |
|
相关推荐
14个回答
|
|
我想,是的,PIC32可以做到这一点。我过去想用PIC24做类似的事情。理论上,UDP“多播”(我从来没有使用过)应该工作。我已经使用TCP做了音频/视频传输,但是我年轻得多,我几乎肯定UDP更适合(更少的开销等等)。
以上来自于百度翻译 以下为原文 I think, yes, that a PIC32 can do that - I wanted to make something similar in the past using a PIC24. And in theory UDP "multicast" (which I never used) should work... I have done audio/video transmission using TCP, but I was much younger and I am almost sure UDP is better suited (less overhead, etc). |
|
|
|
只需广播这些数据包(发送到255.255.255.255),所有的服务器都会看到它们。
以上来自于百度翻译 以下为原文 Just broadcast the packets (send to 255.255.255.255) and all of the servers will see them. |
|
|
|
我不能这样做,因为流量是通过互联网发送出去的。遥远的建筑物在完全分离的网络上。
以上来自于百度翻译 以下为原文 I can't do that as the traffic is sent out over the internet. The remote buildings are miles away on totally separate networks. |
|
|
|
如果不能在同一个LAN上广播,那么,如果是这样的话,你应该使用TCP,而不是UDP。使用它的唯一原因是如果你能广播。
以上来自于百度翻译 以下为原文 Indded, you can't broadcast if they're not on the same LAN. Also, if that's the case, you should be using TCP, not UDP. There's no gurantee UDP packets will get through. The only reason to use it would be if you COULD broadcast. |
|
|
|
TCP并不总是活音频/视频应用的最佳选择,因为它希望保证无差错的传输。UDP在RTP等流媒体原型中是常见的,但在PIC上不太可行。http://e.维基百科…org……iMyPortType协议
以上来自于百度翻译 以下为原文 TCP isn't always the best choice for live audio/video applications because it wants to guarantee error-free delivery. UDP is common in live streaming prototcols like RTP, but those aren't likely feasible on a PIC. https://en.wikipedia.org/...ime_Transport_Protocol |
|
|
|
这就是我在这些单元测试中发现的。使用TCP我有一个问题,在远端断开音频。我没有试着去弄清楚原因。切换到UDP解决了这个问题。我还没有看到没有到达远端的页面出现问题。我意识到在互联网拥塞的情况下可能会出现问题。
以上来自于百度翻译 以下为原文 That is what I discovered in testing of the units. Using TCP I had a problem with audio getting broken up at the remote end. I didn't try to investigate to find out why. Switching to UDP solved the problem. I haven't seen any problems with pages not arriving at the remote end. I realize there "could" be problems in the case of heavy internet congestion. |
|
|
|
也许您可以使用相同的状态机(同一代码)使用不同的UDP套接字发送到多个服务器。为每个连接使用一组单独的上下文变量……数据应该以块的形式发送到每个服务器,这样服务器可能不得不在开始实际输出声音之前缓冲一些数据。
以上来自于百度翻译 以下为原文 Perhaps you can send to several servers using different UDP sockets with the same state machine (same code). Use a separate set of context variables for each connection... Data should be sent in chunks to each server so the server may have to buffer up some data before starting to actually output the sound. /Ruben |
|
|
|
这可能是PIC32。使用URIO模块是不可能的。我现在在远端的环形缓冲器中缓冲1800字节的数据。它运行良好,通过PIC32,我将有更多的RAM用于缓冲。我已经完成了PIC32板设计(4层),并将文件发送到获得板后,最终审查明天。一旦我组装了3个板,我可以尝试从一个客户端发送到两个服务器。该板的设计使得它可以被装配为客户机或服务器。
以上来自于百度翻译 以下为原文 This might be possible with a PIC32. That would not be possible using the USRIO modules. I am presently buffering 1800 bytes of data in a circular buffer at the remote end. It works well and by going to a PIC32 I will have a lot more RAM for buffering. I have finished the PIC32 board design (4 layer) and will send the files off to get boards made after a final review tomorrow. Once I get 3 boards assembled I can try sending to two servers from one client. The design of the board is such that it can be assembled as either a client or a server. |
|
|
|
“实时”是否需要,或者可以在发送完整页面之前缓冲它吗?
以上来自于百度翻译 以下为原文 Is "real time" needed or could you buffer the complete page before sending it ? |
|
|
|
实时不是真正需要的。如果公告持续30秒@每秒8000个样本,那将是240000字节的缓冲。大多数公告只有大约10秒长。因此,缓冲整个公告可能是一个很好的处理方法。
以上来自于百度翻译 以下为原文 Real time is not really needed. If the announcement lasts for 30 seconds @ 8000 samples per second, that would be 240,000 bytes of buffering. Most announcements are only about 10 seconds long. So buffering the entire announcement may be a good way of handling it. |
|
|
|
当你已经使用互联网的时候,我会把网页存储在一个网站上。我会让每一个远程建筑周期性地检查Web服务器站点(也许每30秒一次)。如果一个新的页面可用,我会在响应中传递它。我会在服务器上使用PHP。
以上来自于百度翻译 以下为原文 As you are already using the internet I would store the pages on a web site. I would have each of the remote buildings check the web server site periodically ( maybe once every 30 seconds ). If a new page was available I would deliver it in the response. I would use PHP on the server. |
|
|
|
使用UDP与多播/IGMP,这就是它的目的。
以上来自于百度翻译 以下为原文 Use UDP with multicast/IGMP, that's what it is for. |
|
|
|
是的,正如上面提到的,我对路由和互联网也不太确定。-从来没有这样做过。
以上来自于百度翻译 以下为原文 Yep, as mentioned above I am (too) not sure about routing and the internet... - never did this one. |
|
|
|
我认为UDP具有可能的完全缓冲是前进的方向。如果整个公告在缓冲区中,它可以按顺序发送到多个IPS。我相信多播/IGMP会太复杂,因为这可能意味着路由器/交换机必须在每个远程站点参与。我没有访问路由器的权限。我目前正在UDP广播上发送一个高编号的端口(5000及以上),大多数路由器不会阻塞。
以上来自于百度翻译 以下为原文 I think UDP with possible full buffering is the way to go. If the entire announcement is in a buffer, it can be sent to multiple IPs in sequence. I believe multicast/IGMP would be too complex as it could mean the routers/switches would have to get involved at each remote site. I do not have access to the routers. I am currently sending the UDP broadcasts out on a high numbered port (5000 and above) which most routers don't block. |
|
|
|
只有小组成员才能发言,加入小组>>
5244 浏览 9 评论
2035 浏览 8 评论
1955 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3214 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2261 浏览 5 评论
779浏览 1评论
672浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
598浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
682浏览 0评论
579浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-25 14:55 , Processed in 1.610174 second(s), Total 103, Slave 87 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号