You might be quite underwhelmed by the audio. You'll probably have to do sample dropping/repeating to deal with non-synchronized audio clocks. I think that your proposed solution would work for telephone audio quality with a high latency. For you this probably wouldn't be an issue, but you never know.
I am talking about the number of Ethernet switches, the type of switches, how they are connected, and the number/type of non-audio ethernet devices also on the network.
Network Topology: As the audio quality goes up (and latency goes down) your network topology becomes really important. Other issues like IRQ rate, packet transmit/receive time (not just overall bandwidth), and sometimes packet timing are super important. There are many cases where raw bits-per-second of the Ethernet interface is not the only problem. Using the mic, MCU, and Ethernet interface that you proposed is going to put you into the telephone quality side of things. Pro-audio quality with low latency is super hard. The shorter the latency, the less issues there are with things like audio echo and stuff.īandwidth: Sending telephone quality audio with high latency is the easiest. A latency of <2.5 mS is damn hard to do correctly an robustly. Just saving audio data to a file is a good example of super-long latency, and is one reason why that is also the easiest thing to do. The shorter the latency the harder things are.
#Arduino ethernet udp packet sender Pc
Low-latency: How long it takes the audio to go from the Mic, over the network to the PC, and then used by the PC is called latency. Just saving the data to a file on the PC side of things is easy- using it in a real-time way is hard.
#Arduino ethernet udp packet sender software
There are difficulties and side effects of both of these, which increases the software difficulty immensely. Non-pro applications solve this by doing sample rate conversion or just simple drop/duplicate samples as the audio clocks drift. Doing it in a way that the two devices have a synchronized audio clock is difficult. Your application doesn't sound like pro-audio, but the software task is still not trivial.Īudio Clocking: Transmitting the audio data from point A to point B is relatively easy. The closer you want to pro-audio performance the harder it is. Software: The hardware is honestly the easy part.
(This is pro-audio only, and does not include VOIP or other non-pro products.) Odds are very high that you have heard products where I have designed the audio over ethernet circuitry in them. Before I get into details, let me say that I have probably designed more professional-audio over Ethernet hardware than anyone else- both in terms of number of different PCB designs as well as number of PCBs manufactured and shipped to end customers.
0 kommentar(er)
