Audio über Ethernet senden

Bevor ich ins Detail gehe, möchte ich sagen, dass ich wahrscheinlich mehr professionelle Audio-über-Ethernet-Hardware entwickelt habe als jeder andere – sowohl in Bezug auf die Anzahl verschiedener PCB-Designs als auch auf die Anzahl der hergestellten und an Endkunden gelieferten PCBs. Die Chancen stehen sehr gut, dass Sie Produkte gehört haben, bei denen ich die Audio-over-Ethernet-Schaltung in ihnen entworfen habe. (Dies ist nur Pro-Audio und schließt VOIP oder andere Nicht-Pro-Produkte nicht ein.)

Beginnen wir mit den Problemen:

Software: Die Hardware ist ehrlich gesagt der einfache Teil. Die Software ist schwierig. Je näher Sie der Pro-Audio-Performance kommen wollen, desto schwieriger wird es. Ihre Anwendung klingt nicht nach Pro-Audio, aber die Softwareaufgabe ist immer noch nicht trivial.

Audio Clocking: Die Übertragung der Audiodaten von Punkt A nach Punkt B ist relativ einfach. Es ist schwierig, dies so zu tun, dass die beiden Geräte eine synchronisierte Audiouhr haben. Nicht-Profi-Anwendungen lösen dies, indem sie eine Abtastratenkonvertierung durchführen oder einfach Samples löschen/duplizieren, wenn die Audiotakte driften. Es gibt Schwierigkeiten und Nebenwirkungen von beiden, was die Software-Schwierigkeit immens erhöht. Es ist einfach, die Daten in einer Datei auf der PC-Seite zu speichern – sie in Echtzeit zu verwenden, ist schwierig.

Niedrige Latenz: Wie lange es dauert, bis das Audio vom Mikrofon über das Netzwerk zum PC gelangt und dann vom PC verwendet wird, wird als Latenz bezeichnet. Je kürzer die Latenz, desto schwieriger sind die Dinge. Das einfache Speichern von Audiodaten in einer Datei ist ein gutes Beispiel für superlange Latenzzeiten und einer der Gründe, warum dies auch am einfachsten ist. Eine Latenz von <2,5 mS ist verdammt schwer korrekt und robust zu machen. Je kürzer die Latenz, desto weniger Probleme gibt es mit Dingen wie Audio-Echo und so.

Bandbreite: Das Senden von Audio in Telefonqualität mit hoher Latenz ist am einfachsten. Pro-Audio-Qualität mit geringer Latenz ist superhart. Die Verwendung der von Ihnen vorgeschlagenen Mikrofon-, MCU- und Ethernet-Schnittstelle bringt Sie auf die Seite der Telefonqualität. Es gibt viele Fälle, in denen rohe Bits pro Sekunde der Ethernet-Schnittstelle nicht das einzige Problem sind. Andere Themen wie IRQ-Rate, Paket-Sende-/Empfangszeit (nicht nur Gesamtbandbreite) und manchmal Paket-Timing sind sehr wichtig.

Netzwerktopologie: Wenn die Audioqualität steigt (und die Latenz sinkt), wird Ihre Netzwerktopologie wirklich wichtig. Ich spreche über die Anzahl der Ethernet-Switches, die Art der Switches, wie sie verbunden sind, und die Anzahl/Art der Nicht-Audio-Ethernet-Geräte im Netzwerk. Für Sie wäre das wahrscheinlich kein Problem, aber man weiß nie.

Ich denke, dass Ihre vorgeschlagene Lösung für Telefon-Audioqualität mit hoher Latenz funktionieren würde. Sie müssen wahrscheinlich Sample Dropping / Repeating durchführen, um mit nicht synchronisierten Audiotakten umzugehen. Und das wird nicht so toll. Sie könnten vom Audio ziemlich überwältigt sein. Ich denke auch, dass Sie auf der PC-Seite eine Menge Software zum Schreiben haben werden. Davon abgesehen würde ich das Projekt nicht damit machen.

Wenn ich das Projekt durchführen würde, würde ich mir eines der neuen ARM Cortex-M3- oder M4-Geräte von TI oder Freescale ansehen, das einen 100-MBit/s- oder Gigabit-Ethernet-Controller enthält. Viele dieser Dinge kosten jeweils weniger als 10 US-Dollar und können mit bis zu 100 MHz betrieben werden. Die Menge an RAM und Flash macht das Schreiben von Software viel einfacher.

Zur Unterhaltung verwendet mein aktuelles Audio Over Ethernet-Projekt einen 800 MHz ARM Cortex-A8 mit zwei Gigabit-Ethernet-Ports und führt eine angepasste Version von Linux aus. Das System als Ganzes (nicht nur dieses Cortex-A8-Gerät) kann über 2048 Audiokanäle bei 48 kHz, 32 Bit verarbeiten, mit einer Gesamtsystemlatenz von nur 2,5 ms (einschließlich ADC, DAC, zweimal über das Netzwerk und viele mehr wird bearbeitet). Audiogeräte im Netzwerk haben ihre Sample-Clocks auf weniger als 1 uS synchronisiert, selbst wenn es mehr als 8 Switch-Hops in der Mitte gibt.

Wenn Sie sich Sorgen um die Bandbreite machen, sollten Sie ein Mikro mit eingebautem MAC/PHY verwenden, anstatt extern über SPI verbunden zu sein, wie es beim ENC28J60 der Fall ist. Mein Netzwerkstack unterstützt sowohl den ENC28J60 als auch den internen MAC/PHY einiger PIC 18 wie den 18F67J60, und es gibt einen deutlichen Geschwindigkeitsunterschied, wenn Daten vom Mikro verarbeitet werden müssen.

Ethernet mit 10 Mbit/s ist viel mehr als nötig, selbst für gute Audioqualität. 16-Bit-Samples bei 44 kHz sind beispielsweise 704 kbit/s. Wenn Sie nur die Sprachqualität wünschen, kann sie viel niedriger sein. 12-Bit-Samples bei 10 kHz sind beispielsweise nur 120 kbit/s, und das ist eine sehr gute Sprachqualität.

Der Engpass wird im Umgang mit den Daten im Mikro sein. Eine Abtastrate von 10 kHz ist eine Abtastung alle 100 µs, was bei einem Prozessor mit einer Befehlsrate von 10 MHz alle 1000 Befehle entspricht. Das ist ziemlich viel.

Sie sagten "Ethernet", aber nicht, welche Art von Protokoll Sie verwenden möchten. Wenn Sie vorhaben, rohe Ethernet-Pakete mit einer privaten Protokoll-ID oder ähnlichem zu senden, gibt es nicht viel Overhead, zumal Sie nur senden und wenn der MAC/PHY in den Prozessor integriert ist. In diesem Fall ist dies anhand der obigen Zahlen leicht machbar.

Komplizierter wird es, wenn Sie ein Standard-Netzwerkprotokoll verwenden möchten. Wenn Sie dies tun, werden die meisten Zyklen dorthin gehen, und es wird daher die Grenze der Datenrate sein. Für das Streaming von Audio würde ich UDP verwenden, da es viel einfacher als TCP ist und keinen Empfang, ACKs und dergleichen erfordert.

Ich habe ein Projekt in Arbeit, bei dem das kleine eingebettete System unter anderem Streaming-Audio in Sprachqualität empfangen muss. Ich plane, UDP für das Streaming-Audio zu verwenden. Ich habe einen 18F67J60, auf dem ein vollständiger Netzwerkstapel ausgeführt wird, da dieses Gerät auch für andere Zwecke über TCP kommuniziert. Der Empfang von UDP-Paketen ist ziemlich einfach, sodass ich denke, mit der Bandbreite umgehen zu können. Jedes Mikro, das einen Netzwerkstapel handhabt, ist normalerweise nicht gut für Echtzeitverarbeitung mit geringer Latenz, daher habe ich ein separates Mikro dafür vorgesehen, die Streaming-Audiodaten vom Netzwerkprozessor über SPI auf derselben Platine zu empfangen. Dieser Prozessor verwendet den größten Teil seines RAM als Sample-Puffer. Die Daten vom Netzwerkprozessor werden in Bursts kommen, aber sie müssen mit einer konstanten Rate ausgeschrieben werden. Ich werde wahrscheinlich erst in ein oder zwei Monaten dazu kommen, den Streaming-Audio-Teil dieses Projekts zu implementieren,

Ich habe in der Vergangenheit Arduinos mit 115200 Bd an der seriellen Schnittstelle verwendet, aber ich habe damit aufgehört, weil ich von Zeit zu Zeit Bitfehler erhalten habe. Vielleicht schneidet ein Original-Arduino besser ab als meine billigen chinesischen Nachbauten, aber dafür kann ich keine Garantie geben. Ich denke, daher kommt die 5kByte/s-Faustregel.

Ich habe keine Ahnung von der Leistung der Ethernet-Schilde, es hängt wahrscheinlich vom Schild und der Rechenleistung von Arduino ab. Wenn Sie lediglich ein Audiosignal in ein serielles Digitalsignal umwandeln möchten, sollte dies für den Prozessor kein großes Problem darstellen.