Hallo zusammen! Für mein Audio over Ip Projekt muss ich mir ein Evalboard zulegen. Jedoch bin ich damit etwas überfordert. Die meisten Boards gerade von Xilinx haben keine AD-Wandler mehr. Nur die Spartan 3 Serie. Ist das richtig? Das Board soll nicht so teuer sein (ca. 500). Eventuell ein Board mit Softcore und DSP. Gibts da vielleicht spezielle Boards? Hab bis jetzt nur mit den Xilinx tools gearbeitet. Hat da jemand Erfahrung und kann mir helfen? Gruß Mathias
Schau dir mal die Altera-Boards an. Die haben fast alle einen Audio-Codec drauf. Das DE2-115 zum Beispiel hat 2xGbE und Audio zusammen mit einem dicken FPGA. Gruß Marius
Mathias schrieb: > Für mein Audio over Ip Projekt muss ich mir ein Evalboard zulegen. > Jedoch bin ich damit etwas überfordert. Das wäre jetzt nicht das Problem... > Die meisten Boards gerade von Xilinx haben keine AD-Wandler mehr. Nur > die Spartan 3 Serie. Ist das richtig? Aber warum machst du die Wahl des FPGAs vom Vorhandensein eines ADCs auf dem EVAL-Board abhängig? > Das Board soll nicht so teuer sein (ca. 500). Für 0,5k€ kannst du dich problemlos mit Hardware versorgen. > Eventuell ein Board mit Softcore und DSP. Mit den Lizenzen für einen Softcore wirds dann aber knapp. Ich hätte da noch 2 Fragen: Was willst du denn eigenlich machen? Warum brauchst du eigentlich ein FPGA?
Der DE2-115 hat einen Soundchip drauf: WM8731. Der hat Line In, Line Out und Mic In. 2* Ethernet hat der auch. Doch warum muss das über einen FPGA laufen? Ich habe schon vor 10 Jahren das mit einem einfachen (damals) PC gemacht. Normale Soundkarte, normales Ethernet, ca 1000 Zeilen Code, und dann war es fertig. Heute kann man kleine Raspis nehmen, mit einem USB-Soundadapter, denn der eingebaute Sound ist grausam. Ist man für weniger als 100 Euro dabei. Alleine am Ethernet-Kram auf dem FPGA sitzt man schon Monate (ja, ich habe Ethernet auf dem DE2-115 implementiert).
Ich will 32 Audiostream (96kHz) mittel FPGA und Ethersound mit niedrigen Latenzen zu anderen "Geräten" versenden, wahrscheinlich mit TDM16. Die Daten müssen A/D gewandelt werden oder Digital aus TDM- Signalen gewonnen werden. Das ganze mit einem FPGA zu machen ist nur ne Überlegung. Bin noch ziemlich am Anfang.
Hier gibts so ein Embedded Kit des Spartan 6. Leider ohne AD/Wandler. Aber wenn man die gut nachrüsten kann. Ist Da die Embedded Version von Ise dabei? Dann müsste ja auch der MicroBlaze dabei sein. Oder? http://www.xilinx.com/products/boards-and-kits/DK-S6-EMBD-G-image.htm
Spontan würde mir als Lösung ein kleiner DSP einfallen, zum Beispiel von Analog die Sigma DSP's sollten da genügen. Sehr leicht mittels grafischer Oberfläche zu programmieren (oder besser gesagt zusammenklicken was man braucht), ein paar ADC's anschließen und die verschiedenen I2S Signale am DSP Ausgang mit TDM Stream ausgeben (aber meines Wissens nach nur TDM8). Gibt unter anderem Modelle bis zu 24x I2S oder 3xTDM8 I/O z.B. ADAU1445, damit solltest du deine 32 Kanäle in einem DSP abdecken können (oder meintest du 32 digitale Streams = 64 Kanäle?) Ich spiele auch schon seit längerem mit dem Gedanken eines eigenen Audio over IP Systems. Als Sender eine virtuelle Multichannel Soundkarte (so wie bei DANTE) und wollte eventuell für die Endgeräte Cortex M3 von NXP verwenden, da ist bereits I2S und Ethernet on Board. Ist aber alles noch im sehr frühen Stadium... Thomas
Marius Wensing schrieb: > Das DE2-115 zum Beispiel hat 2xGbE und Audio zusammen > mit einem dicken FPGA. Vor allem hat es einen leicht zu beschreibenden RAM-Chip.
Die Firma Ethersound bietet auch Systeme an die auf FPGAs basieren... http://www.ethersound.com/download/files/EtherSoundTechnology.pdf
PittyJ schrieb: > Alleine am Ethernet-Kram auf dem FPGA sitzt man schon Monate (ja, ich > habe Ethernet auf dem DE2-115 implementiert). Welches Protokoll hast Du verwendet?
Juergen S. schrieb: > PittyJ schrieb: >> Alleine am Ethernet-Kram auf dem FPGA sitzt man schon Monate (ja, ich >> habe Ethernet auf dem DE2-115 implementiert). > Welches Protokoll hast Du verwendet? Ich habe nur UDP-Pakete verschickt. Das ist zustandslos und geht einfacher. Für irgendwas mit TCP hätte man noch die gesamte Sicherungsschicht mit implementieren müssen. Das war für mein Projekt nicht nötig, und UDP hat mir vom Aufwand her schon gereicht.
> > @Thomas: Nee sind 32 Kanäle ist schon richtig. Und wieviel Bit soll der ADC haben?
24bit für ADC/DAC sind eigentlich üblich heutzutage im Audio Segment. Hier ist auch noch der Link für den DSP: http://www.analog.com/en/processors-dsp/sigmadsp/adau1446/products/product.html Thomas
Es hat sich was neues ergeben: Die Audiodaten sollen mit Hilfe eines Fpga über Ethernet verteilt werden (32- Kanäle an mehrere Empfänger). Die Audio-daten können schon digital gewandelt (mehere TDM4- Signale) abgegriffen und an das FPGA weitergeleitet werden. In dem FPGA sollen dann die Audiodaten zusammengefasst werden und an andere "Stationen" mit FPGA (z.B. TDM16) über Ethernet gesendet werden. Dort wieder in TDM4 gewandelt werden und an ein DSP weitergeleitet werden. Ist es Ratsamer: - Ein normales FPGA zu nuten. - Eine FPGA mit Softcore ( Xilinx Kintex-7 FPGA Embedded Kit) - oder ein Hardcore mit Programmierbarer Logic (Xilinx Zynq-7000 SoC ZC702 Evaluation Kit)
Mathias schrieb: > Ist es Ratsamer: > > - Ein normales FPGA zu nuten. > - Eine FPGA mit Softcore ( Xilinx Kintex-7 FPGA Embedded Kit) > - oder ein Hardcore mit Programmierbarer Logic > (Xilinx Zynq-7000 SoC ZC702 Evaluation Kit) Das hängt davon ab, ob Ihr wirklich einen (c-)programmierbaren Controller in Euren FPGAs braucht. Falls ja, Softcores sind nicht für super-Performance bekannt, eher für Flexibilität. Bei Zynq bekommt man einen relativ schnellen Cortex, ist aber dn ziemlich festgelegt. Außerdem: Wieviel Erfahrung habt Ihr mit FPGA-Designs? Wieviel Geld steht zur Verfügung? Wie schnell muß das Projekt fertig werden? Was darf das Produkt am Ende kosten? Duke
Duke Scarring schrieb: > Außerdem: > Wieviel Erfahrung habt Ihr mit FPGA-Designs? Ich bin wohl der einzige hier der sich damit bissl auskennt. Hab mit dem Spartan 3E viel auf der Uni gemacht. > Wieviel Geld steht zur Verfügung? Solange es fixe kosten ist es Verhandlungssache. Das Board + IP so ca 2000€ > Wie schnell muß das Projekt fertig werden? Das ganze Projekt hat ein ehrgeiziges Ziel. Juli nächstes Jahr. Meine Teilprojekt soll so ca. 6-7 Monate dauern. > Was darf das Produkt am Ende kosten? Die Stream über Fpga zu versenden ist nur ein Teilprojekt. Je günstiger desto besser. Aber die Zynq- Chips und die benötigte Peripherie ist ja jetzt nicht so teuer. oder?
Sehe ich das richtig: Du willst 32 Kanäle Audio sampeln (24 Bit bei 192 kHz?) und per FPGA auf Ethernet bringen? Und das Problem ist die Hardware, bzw. sind die AD-Wandler? Ein Board mit 32 AD-Kanälen out-of-the-box ist wahrscheinlich schwer zu finden. Du kannst aber ein aktuelles SP605 oder was von der 7er-Serie nehmen und per FMC erweitern. Vier- oder Achtkanal-FMC-Karten sollten sich finden lassen. Damit kannst Du erstmal einen Prototypen entwickeln. Einen Prozessor oder Softcore würde ich nur mit integrieren, wenn auf der Ethernetseite mehr als UDP gebraucht wird. Dann können die langsamen Protokolle in Software gehandelt werden. Duke
Hi Duke. Duke Scarring schrieb: > Sehe ich das richtig: Du willst 32 Kanäle Audio sampeln (24 Bit bei 192 > kHz?) und per FPGA auf Ethernet bringen? Ja hat sich alles bissl geändert. Die FPGA soll die gewandelten Streams (insgesamt 32 Kanäle) (Streams TDM 4 oder TDM8) von einem ADAU1446 erhalten. Die Daten sollen dann über Ethernet verteilt werden. Ein Testboard für den Wandler ist das EVAL- ADAU 144X EBZ. Als Ethernetprotokoll soll wohl TCP (für eventuelle Steuerungsdaten und UDP (für den eigentlichen Stream) vorhanden sein. > > Und das Problem ist die Hardware, bzw. sind die AD-Wandler? Das Problem ist nur die Hardware die AD- Wandler sind vorgegeben. Es gibt ip- Cores für Ethernet. Hier TCP und UDP. http://www.intilop.com/resources/product_briefs/10G_TCP+UDP_Offload+EMAC+Host_IF%20Ultra-Low%20Latency%20%28SXTOE+UOE%29.pdf Weiss jemand in welchem Rahmen die sich so preilich bewegen? Ich habe mir als Board mal das Kintex 7 embedded rausgesucht: http://www.xilinx.com/products/boards-and-kits/DK-K7-EMBD-G.htm. Ich erstell mal noch ein Blockschaltbild zum besseren Verständnis.. Gruß Mathias
Also ich würde das ernsthaft mit PCs machen. Die Latenz ist dadurch begrenzt, wie klein die Pakete sein dürfen. Da ist eine vernünftige untere Grenze 200 Bytes. Bei 32 Kanälen a 3 Bytes macht das 2 Abtastwerte. macht also 48k Interrupts pro Sekunde. Das sollte ein PC heute mit einem Echtzeitlinux noch schaffen.
Um was gehts bei dem Projekt? Oben schreibst du "Ich will 32 Audiostream (96kHz) mittel FPGA und Ethersound mit niedrigen Latenzen zu anderen "Geräten" versenden". Heißt das, du möchtest das Protokoll von Ethersound auf eigener Hardware implementieren? Den Sinn dahinter verstehe ich nicht so ganz, von rechtlichen Aspekten mal abgesehen... Entweder man nimmt was proprietäres wie Ethersound und kauft sich IP und Support beim Hersteller oder man nimmt was offenes wie AVB oder RAVENNA und implementiert es selbst (wobei man da in der Praxis auch wieder auf IP zurückgreifen dürfte, vor allem wenn man so einen engen Zeitrahmen hat und es am Ende auch funktionieren muss). Audio-over-IP mit niedriger Latenz ist wesentlich mehr als Samples in Pakete zu packen, ich würde sogar behaupten, dass das noch der geringste Aufwand dabei ist. Themen wie clock recovery dürften da wesentlich mehr Hirnschmalz erfordern.
Angehängte Dateien:
Holger B. schrieb: > Um was gehts bei dem Projekt? Oben schreibst du "Ich will 32 Audiostream > (96kHz) mittel FPGA und Ethersound mit niedrigen Latenzen zu anderen > "Geräten" versenden". Ja das wahr wohl ein Tippfehler. Wollte Ethernet schreiben und natürlich nicht deren System nachbauen. Hier mal das Blockschaltbild dazu.
Muss das zwangsweise mit FPGAs gemacht werden? Unter den gegebenen Bedingungen ("Ich bin wohl der einzige hier der sich damit bissl auskennt", "Das ganze Projekt hat ein ehrgeiziges Ziel. Juli nächstes Jahr. Meine Teilprojekt soll so ca. 6-7 Monate dauern.") sehe ich da nur geringe Erfolgsaussichten. Oder ihr nehmt mehr Geld in die Hand und kauft ein FPGA-Design eines Dienstleisters. Ist das eine kommerzielle Geschichte oder ein Uniprojekt?
Hi Mathias, schau dir mal die Homepage vom Audinate an. Die haben genau das entwickelt, was du machen willst. Deren Brookly II Karte dürfte dir viel Entwicklungsarbeit abnehmen. Grüße
Gregor schrieb: > Deren Brookly II Karte dürfte dir viel Entwicklungsarbeit abnehmen. Ja, das ist ein schönes Produkt. Schneller und günstiger als damit bekommt man Audio-over-IP nicht integriert.
Geb mir bitte mal eine Info wenn du Erfolg dabei hast mit Audinate Kontakt aufzunehmen zwecks Brooklyn II Karte - ich hab das auch mal vor einiger Zeit versucht und keine Antwort bekommen. Bin aber dafür in deren News-Emailverteiler gelandet... :( Thomas
Nur der Vollständigkeit halber: Von Marvell gibt es den 88E7221, ein SoC mit ARM9 CPU, 2x FE, USB2.0 und 2xTDM8 IO für 16 Audiokanäle full-duplex. http://www.marvell.com/switching/assets/Link_Street_88E7221.pdf Der wäre für die Anwendung hier zu schwach, ist aber momentan der interessanteste Chip für kleine AVB Endpoints auf dem Markt.
Ich hab den Kontakt mit Audinate hinbekommen. Am Besten ist es die Info@Augdinate.com anzuschreiben oder direkt den Herrn Steve Greenall. Mit dem Webformular kommt man net weit.
PittyJ schrieb: > Alleine am Ethernet-Kram auf dem FPGA sitzt man schon Monate (ja, ich > habe Ethernet auf dem DE2-115 implementiert). Kommt aber drauf an, was man da realisieren will. Ein einfaches UDP schafft man locker in einem Monat. Mit einem FPGA ist das eher einfacher, als mit einem DSP, wegen der Ankopplung an den PHY. Wenn Du eine MAC bedienen willst, würde ich einen SoftCore nehmen. Wenn die Audiodaten noch komprimiert werden sollen, würde ich spätestens auf einen DSP gehen.
Ein einfaches UDP > schafft man locker in einem Monat. Mit einem FPGA ist das eher > einfacher, als mit einem DSP, wegen der Ankopplung an den PHY. Wenn du dich damit nicht mal täuschst. Der FPGA hat eine hohe Flexibilität. die ersten 60% sind auch schnell erreichbar. Die letzten Meter sind schwere Kost. Hardwareentwicklung dauert auf jendenfall länger.
So wie ich das sehe, wird wohl AVB das Rennen machen im "Kampf der Technologien und Protokolle". Spricht einiges dafür: - Standardisiert durch die IEEE, da ging es in den letzten Monaten doch gewaltig voran - lizenzfrei und Quellen verfügbar - Audinate mit DANTE als Marktführer hat mehr oder weniger angedeutet, das man mittels Firmware Updates in Zukunft auch "AVB sprechen will/kann" - damit wären bestehende Geräte wie z.B. Yamaha Mixer kompatibel - Einige Schwergewichte aus Professional Audio und Netzwerk unterstützen bereits AVB, zum Beispiel MEYERSOUND und NETGEAR. Zudem ist in Apple Macs mit MacOSX 10.8 und Ethernet mit Broadcom 5701 Chips bereits AVB implementiert, es ist keine weitere Hardware nötig um Streams per AVB abzuspielen! Also meiner Meinung nach - auf AVB setzen und alles wird gut! :) Ich hab hier übrigens noch einen Link als Alternative zu den DANTE Karten (Habe immer noch keinen Preis aber ich gehe von aus das die DANTE Karten teurer sind wegen Lizenzen!) http://www.dsp4you.com/products/avb-oem-series Thomas
PittyJ schrieb: > Ich habe nur UDP-Pakete verschickt. Das ist zustandslos und geht > einfacher. Ich meinte damit, ob Du ein spezielles Audio-Protokoll implementiert hast? Es gibt ja da einige Standards. Wahrscheinlich aber eher proprietär?
Thomas F. schrieb: > So wie ich das sehe, wird wohl AVB das Rennen machen im "Kampf der > Technologien und Protokolle". Spricht einiges dafür: > > - Standardisiert durch die IEEE, da ging es in den letzten Monaten doch > gewaltig voran > - lizenzfrei und Quellen verfügbar Im Prinzip ja, aber... ;) Es gibt zwar das ein oder andere Projekt mit Codeschnipseln, aber um etwas serienreifes hinzubekommen ist noch ein enormer Aufwand nötig. Und bei den Preisen für die bisher erhältliche kommerzielle IP fällt man auch rückwärts vom Stuhl! Außerdem möchte die Avnu auch einen schönen Batzen Geld sehen, wenn man ein von ihnen zertifiziertes AVB-Produkt vermarkten möchte. Und ohne deren Zertifizierung wird sich meiner Einschätzung nach ein Produkt für den professionellen Markt nicht durchsetzen können. > - Audinate mit DANTE als Marktführer hat mehr oder weniger angedeutet, > das man mittels Firmware Updates in Zukunft auch "AVB sprechen > will/kann" - damit wären bestehende Geräte wie z.B. Yamaha Mixer > kompatibel Ja. Das ändert aber nix dran, dass die Dante-Implementierungen meiner Meinung nach zu teuer für viele Geräte sein dürften. Klar, bei nem Mischpult für xxk€ macht das nix, aber für Geräte <1000€ ist das schon ein massiver Brocken in den COGS. Und ja, Dante Ultimo ist bekannt, aber es fehlt meiner Meinung nach etwas in der Mitte. > - Einige Schwergewichte aus Professional Audio und Netzwerk unterstützen > bereits AVB, zum Beispiel MEYERSOUND und NETGEAR. Zudem ist in Apple > Macs mit MacOSX 10.8 und Ethernet mit Broadcom 5701 Chips bereits AVB > implementiert, es ist keine weitere Hardware nötig um Streams per AVB > abzuspielen! Es schreiben zwar viele "AVB" auf ihre Produkte, von herstellerübergreifender Interoperabilität ist aber noch nicht viel zu spüren. Da fehlt es noch ganz gewaltig an den höheren Layern (1722.1 etc.) Und da du gerade Netgear ansprichst, der GS724T AVB-Switch ist genau so ein Beispiel für mangelnde Kompatibilität. Dort ist 802.1Qat nur als Draft 5 implementiert, was ihn außerhalb des Harman-Universums in Sachen AVB komplett nutzlos macht. Da gibt es bessere, das Maß der Dinge ist hier momentan wohl Extreme Networks. > Also meiner Meinung nach - auf AVB setzen und alles wird gut! :) Hoffentlich, aber bis es soweit ist werden noch Jahre vergehen. > Ich hab hier übrigens noch einen Link als Alternative zu den DANTE > Karten (Habe immer noch keinen Preis aber ich gehe von aus das die DANTE > Karten teurer sind wegen Lizenzen!) Das Brooklyn-Modul von Audinate an sich ist billiger als man denkt, nur wird man es als Privatperson oder Kleinunternehmer nicht bekommen. Meiner Meinung nach aber trotzdem für viele Zwecke noch zu teuer und nur eine Übergangslösung, bis irgendwann die Mikrocontroller die nötigen Erweiterungen an ihrer MAC implementiert haben und man eben keine externe Hardware mehr für AVB braucht. > http://www.dsp4you.com/products/avb-oem-series Jupp, die Kärtchen sind einen näheren Blick wert, und Tony von dsp4you ist Anfragen von Bastlern gegenüber womöglich aufgeschlossener als die australische Konkurrenz ;)
Holger B. schrieb: > Außerdem möchte die Avnu auch einen schönen Batzen Geld sehen, wenn man > ein von ihnen zertifiziertes AVB-Produkt vermarkten möchte. Das ist immer das Problem, bei der Geschichte. Man hat noch keinen Strich im Design gezogen und zahlt schon für den Standard. Da machen dann selbst OS-Projekte keinen Sinn.
Schaut Euch doch mal das hier an: http://www.xmos.com/applications/avb Vielleicht ist das eine Gute Lösung für das ganze Projekt.
Nun ja, XMOS ist ja offensichtlich der Haus- und Hoflieferant für alle existierenden (und wahrscheinlich auch zukünftigen) AVB Lösungen. Wie schon weiter oben gesagt, ich bin der Meinung AVB wird sich durchsetzen. Offene Lizenz ist nun mal ein Argument. Die Phase "Ich hätte da auch noch ein System anzubieten" ist ofensichtlich vorbei - nur das allmächtige HARMAN International könnte da noch was aus dem Hut zaubern und pushen, aber ich glaube nicht daran. DANTE wird als bereits etabliertes System bestehen bleiben, erst recht wenn sie AVB offiziell unterstützen. Allerdings mußte ich kürzlich bei einem Projekt erschreckend feststellen wie dünn doch selbst beim Marktführer DANTE der Markt zum Beispiel für "einfache" Breakout Boxen (z.B. DANTE ->AES/EBU) ist, um auf andere Systeme zu kommen. Ich hoffe auch hier wird sich etwas tun mit AVB. Zertifizierung hin oder her, wenn das System läuft dann läuft es :) Vielen wird eine Zertifizierung durch AVnu egal sein, erst recht bei preissensitiven kleineren Projekten. Wo wir gerade von einfachen Lösungen sprechen, wie seht ihr die Chance zum Beispiel für kleine Endpunkte (AVB in -> 1 Stereo in/out) zum Beispiel einen Cortex M3 zu verwenden, Ethernet und I2S sind bei NXP LPC1768 schon on Chip. Wenn man die AVB Sourcecodes verwendet müßte doch eine Portierung schneller sein als eine eigene Entwicklung komplett von Null zu beginnen - oder sehe ich das falsch? Thomas
Moin! Thomas F. schrieb: > Nun ja, XMOS ist ja offensichtlich der Haus- und Hoflieferant für alle > existierenden (und wahrscheinlich auch zukünftigen) AVB Lösungen. Naja, das stimmt nicht so ganz ;). Für kleine Kanalzahlen ist das momentan das interessanteste Paket, allerdings gibt es durchaus Alternativen. LabX ist beispielsweise im Bereich FPGA sehr aktiv, basierend auf der Referenzimplementierung von Xilinx. Aber auch die SoC von Marvell oder Broadcom sind sehr interessant und auch preislich der Hammer, allerdings schauen letztere dich unter erwarteten sechsstelligen Jahresumsätzen nicht einmal an, und Marvell ist auch recht zickig. > Wie > schon weiter oben gesagt, ich bin der Meinung AVB wird sich durchsetzen. > Offene Lizenz ist nun mal ein Argument. Die Phase "Ich hätte da auch > noch ein System anzubieten" ist ofensichtlich vorbei - nur das > allmächtige HARMAN International könnte da noch was aus dem Hut zaubern > und pushen, aber ich glaube nicht daran. DANTE wird als bereits > etabliertes System bestehen bleiben, erst recht wenn sie AVB offiziell > unterstützen. Harman hat massiv die Entwicklung von AVB gepusht, da findet man einige Namen von denen in den Standards. Hier sehe ich einzig noch RAVENNA von Lawo als Konkurrenz, die sind aber mehr im Broadcast-Bereich aktiv. > Allerdings mußte ich kürzlich bei einem Projekt erschreckend feststellen > wie dünn doch selbst beim Marktführer DANTE der Markt zum Beispiel für > "einfache" Breakout Boxen (z.B. DANTE ->AES/EBU) ist, um auf andere > Systeme zu kommen. Ich hoffe auch hier wird sich etwas tun mit AVB. Das hab ich auch schon festgestellt, aber da wird sich sowohl bei Dante als auch bei AVB etwas tun. > Zertifizierung hin oder her, wenn das System läuft dann läuft es :) > Vielen wird eine Zertifizierung durch AVnu egal sein, erst recht bei > preissensitiven kleineren Projekten. Das mag zutreffen, wenn ich eine Installation komplett mit Geräten eines Herstellers ausstatten kann, da wird der schon dafür sorgen, dass es funktioniert. Aber der Witz ist ja gerade, dass das auch herstellerübergreifend funktionieren soll, und da würde ich als Planer darauf bestehen, dass die Geräte zertifiziert sind, sonst hab ich später den Ärger bei der Inbetriebnahme an der Backe. Momentan ist das definitiv nicht der Fall! > Wo wir gerade von einfachen Lösungen sprechen, wie seht ihr die Chance > zum Beispiel für kleine Endpunkte (AVB in -> 1 Stereo in/out) zum > Beispiel einen Cortex M3 zu verwenden, Ethernet und I2S sind bei NXP > LPC1768 schon on Chip. Wenn man die AVB Sourcecodes verwendet müßte doch > eine Portierung schneller sein als eine eigene Entwicklung komplett von > Null zu beginnen - oder sehe ich das falsch? Für einen Mikrocontroller ohne die nötigen Erweiterungen der MAC wird das nie funktionieren. Man braucht mindestens eine MAC, die ein Timestamping der Pakete in Hardware erlaubt (Stichwort PTP, IEEE1588 etc.), sonst ist keine vernünftige Synchronisierung der Endpoints realisierbar. Auch der Traffic Shaper sollte hardwareunterstützt sein, mit zusätzlichen Queues usw. Solche Microcontroller gibt es durchaus, das ist aber eine ganz andere Kampfklasse als der von dir genannte (TI Jacinto, Freescale i.MX6). Die µC-Implementierungen, die ich bisher kenne, basieren alle auf Linux, da brauchts schon etwas mehr. Und nochmal, für die höheren Layer sehe ich noch keine offene Implementierung, und auch das was bisher so verfügbar ist sind allenfalls Fragmente, die nicht direkt produktiv verwendet werden können. Wenn man Stand heute eine funktionierende Implementierung möchte muss man sehr, sehr tief in die Tasche greifen. Mag sein, dass sich das eines Tages ändert.
Hat mittlerweile schon jemand etwas Erfahrung mit AVB sammeln können? Ich habe mir das AVB reference design kit von XMOS bestellt, aber noch keine PC-Anbindung unternommen. Mein Kenntnisstand: - Mac OS X unterstützt AVB nativ - für Windows gibt es eine Karte mit AVB-Stack (AVB <-> ASIO) http://www.echoavb.com/streamware-nic1.php - für Linux gibt es mit https://github.com/intel-ethernet/Open-AVB Low-Level-Treiber für I210-Karten und Server für Zeitsynchronisation, aber keine Audio-API. Bei Endgeräten gibt es schon einige die mit AVB werben, aber das nur im Rahmen eines proprietären Systems. Zum Beispiel hat Meyer Sound mit "D-MITRI" ein paar schöne Geräte (http://www.meyersound.de/pdf/products/d-mitri/daio-168_ppi.pdf), aber bezüglich Interoperabilität mit anderen AVB-Geräten findet man nichts.
:
Bearbeitet durch Admin
Andreas Schwarz schrieb: > Hat mittlerweile schon jemand etwas Erfahrung mit AVB sammeln können? > Ich habe mir das AVB reference design kit von XMOS bestellt, aber noch > keine PC-Anbindung unternommen. Mein Kenntnisstand: > - Mac OS X unterstützt AVB nativ Richtig. AVB-Support muss aktiviert werden (ein Befehl auf der Kommandozeile) und schon stehen die XMOS-Boards als Audiogerät zur Verfügung. Geht aber nur mit aktuellen MACs. > - für Windows gibt es eine Karte mit AVB-Stack (AVB <-> ASIO) > http://www.echoavb.com/streamware-nic1.php Funktioniert auch, allerdings nicht mit externem 1722.1-Controller. > - für Linux gibt es mit https://github.com/intel-ethernet/Open-AVB > Low-Level-Treiber für I210-Karten und Server für Zeitsynchronisation, > aber keine Audio-API. Das war das, was ich mit "Fragmenten" meinte ;). Aber ich denke mal, dass das nur eine Frage der Zeit ist bis sich die Opensource-Gemeinde der Sache annimmt. Wobei die Implementierung von 1722.1 schon ein ziemlicher Brocken ist, soweit ich das überblicken kann. > Bei Endgeräten gibt es schon einige die mit AVB werben, aber das nur im > Rahmen eines proprietären Systems. Zum Beispiel hat Meyer Sound mit > "D-MITRI" ein paar schöne Geräte > (http://www.meyersound.de/pdf/products/d-mitri/daio-168_ppi.pdf), aber > bezüglich Interoperabilität mit anderen AVB-Geräten findet man nichts. Angeblich haben die bereits 1722.1 gemäß der kürzlich veröffentlichten finalen Version implementiert...
> Hier sehe ich einzig noch RAVENNA von Lawo als Konkurrenz, die sind aber > mehr im Broadcast-Bereich aktiv. Ravenna ist doch von ALC (Another Lawo Company ;) ). Wobei die wesentlichen Teile von Ravenna jetzt als AES67 standardisiert wurden, also "zielgruppengerecht". IMO ist das auch ein anderer Ansatz als die IEEE-Variante, weil bei Ravenna einfach bereits existierende Standards (PTP für die Zeit, RTSP fürs Multicast/Unicast-Streaming und Zeroconf/mDNS/Avahi fürs Service-Announcement) kombiniert werden. Da ist eigentlich von SW-Seite fast alles schon vorhanden...
Hab mir grad den ganzen Thread durchgelesen. Wieder mal super Beispiel das Standardisierung super ist, am besten wenn es viele verschiedene Gremien gibt ;-) Kann mich jemand mit einem kurzen Abschnitt aufklären, wo jetzt noch der Standard AES50 der von Music Corp. (Midas, Behringer) gepuscht wird einzuordnen ist?
vilu schrieb: >> Wo wir gerade von einfachen Lösungen sprechen, wie seht ihr die Chance >> zum Beispiel für kleine Endpunkte (AVB in -> 1 Stereo in/out) zum >> Beispiel einen Cortex M3 zu verwenden, Ethernet und I2S sind bei NXP >> LPC1768 schon on Chip. Wenn man die AVB Sourcecodes verwendet müßte doch >> eine Portierung schneller sein als eine eigene Entwicklung komplett von >> Null zu beginnen - oder sehe ich das falsch? > > Für einen Mikrocontroller ohne die nötigen Erweiterungen der MAC wird > das nie funktionieren. Man braucht mindestens eine MAC, die ein > Timestamping der Pakete in Hardware erlaubt (Stichwort PTP, IEEE1588 > etc.), sonst ist keine vernünftige Synchronisierung der Endpoints > realisierbar. Auch der Traffic Shaper sollte hardwareunterstützt sein, > mit zusätzlichen Queues usw. Als zwei Chiplösung könnte das vielleicht funktionieren: - Kleinen uC mit I2S - Ethernet PHY + MAC mit PTPv2 unterstützung von Micrel http://www.micrel.com/index.php/en/products/lan-solutions/ieee-1588/article/4-ksz8441hl.html Laut Digikey kostet der 16 US$.
Christoph Z. schrieb: > Kann mich jemand mit einem kurzen Abschnitt aufklären, wo jetzt noch der > Standard AES50 der von Music Corp. (Midas, Behringer) gepuscht wird > einzuordnen ist? AES50 benutzt nur die PHY-Layer von Ethernet und ist daher inkompatibel zu gängigen aktiven Netzwerkkomponenten. Vorteil ist, dass die Implementierung im Gegensatz zu den Audio-over-IP Netzwerken sehr schlank ist und die Latenzen sehr niedrig sind. Ich würde das am ehesten als modernen MADI-Nachfolger für Punkt-zu-Punkt-Verbindungen sehen. Christoph Z. schrieb: > Als zwei Chiplösung könnte das vielleicht funktionieren: > - Kleinen uC mit I2S > - Ethernet PHY + MAC mit PTPv2 unterstützung von Micrel > > http://www.micrel.com/index.php/en/products/lan-solutions/ieee-1588/article/4-ksz8441hl.html > > Laut Digikey kostet der 16 US$. Für das Geld bekommst du schon längst µCs/SoCs, die das alles integriert haben, die sind halt nicht besonders bastlerfreundlich, und das AVB Stack hast du dann auch noch nicht, was sicher das größere Problem ist. Exemplarisch seien mal Freescale Vybrid oder der 88E7221 von Marvell genannt. Ich glaube nicht, dass irgendein Hersteller in einem neuen Chipdesign noch MACs ohne AVB/TSN verbaut, da das Thema momentan in Automotive und Industrial weite Kreise zieht. Die Auswahl an passenden Chips wird also ständig größer. Ist die Frage, wann Softwareimplementierungen auf breiter Ebene verfügbar sind. Die wenigen Anbieter, die da aktuell etwas auf Tasche haben rufen dafür Preise jenseits von gut und böse auf. Stand heute ist man meiner Meinung nach mit XMOS am besten beraten wenn man mal in die Thematik reinschnuppern möchte.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.