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.
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.
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.
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.
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.
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.
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.
