Hallo zusammen, ich bin vor dem Abschluss meines E-Technik-Studiums und wollte mir ein paar Meinungen über eine Aufgabenstellung einholen. Es geht darum I2S-Signale von acht Mikrofonen in einem FPGA aufzunehmen und diese über einen langen "Tunnel" zu einem weiteren FPGA zu übertragen. Dort werden die Signale wieder in I2S-Signale aufgeteilt. Die Übertragungsstrecke muss dabei mindestens 30m hergeben. Das ganze wird so gelöst, da alles "live" passieren muss, da es mehrere von diesen Lösungen parallel geben soll und alles direkt verarbeitet und ausgewertet wird, also synchron laufen muss. Es gibt die Überlegung die Signale hintereinander über ein Netzwerkkabel mit höherer Frequenz zu übertragen. Da acht einzeladern zur Verfügung stehen, teilen sich die Leitungen also auf in VCC/GND, +WS/-WS, +BCK/-BCK und +DOUT/-DOUT. Wasserdichte RJ45 Stecker/ Kupplungen gibt es ja, was erforderlich ist. Die zweite Überlegung ist die Daten mit einem Serialisierer/ Deserialisierer (SerDes) zu übertragen. Also fertige ICs zu verwenden falls es welche gibt, die das hergeben. Und eine dritte Überlegung ist, die Daten nach dem FPGA umzuwandeln und über (einen) Lichtwellenleiter zu übertragen. Die Spannungsversorgung müsste man dann parallel neben der Leitung herziehen. Mich würde jetzt interessieren, was Ihr zu den Möglichkeiten sagt, ob ich etwas gleich vergessen sollte, was mehr/ weniger geeignet wäre und warum, oder ob Ihr andere, evtl. bessere Ideen habt. Vielen Dank im Voraus und viele Grüße von Thorsten
Das letzte mal als ich nachgeschaut hab gab es für so nen Kram schon fertige Lösungen im PA Bereich... Die Uni Luftschlösser mal wieder die täglich das Rad neu erfinden. Mit FPGA nur so um sich werfen, ich glaubs nicht...
Hallo Egon, danke für deinen Beitrag. Ich bin gerne für einen genaueren Hinweis/ Verweis offen. Ich möchte die Problemstellung gerne lösen, dazu muss nichts altes neu erfunden werden. Ich greife darauf gerne zurück. Die FPGAs dienen zur Datenverarbeitung/ -umwandlung. Es müssen ja Daten von mehreren Mikrofonen verarbeitet werden. Wenn du einen genaueren Hinweis hast bin ich dir sehr dankbar. Viele Grüße Thorsten
I2S unterstützt von sich aus aber erstmal nur 2 Kanäle, umgeschaltet durch die WClk. Du musst dir also überlegen, wie du acht Words mit einem WClk umschalten willst. Das geht m.E. nur, wenn du die WCLK umdefinierst in eine Serielle 'Kanalnummer'(vorzugsweise synchron mit der BClk), die beim Multiplexen auf W+/- aufgelegt wird und beim Demux seriell dekodiert wird und den Demux umschaltet. Am Ausgang des FPGA muss aber wieder eine kompatible WClk liegen.
Moin, Thorsten D. schrieb: > Es geht darum I2S-Signale von acht Mikrofonen in einem FPGA aufzunehmen > und diese über einen langen "Tunnel" zu einem weiteren FPGA zu > übertragen. Da wuerd' ich auf vorhandene Protokolle und Standards setzen, eben um das Rad nicht dauernd neu zu erfinden. Von der Datenrate her geht 8x unkomprimiertes Audio ueber eine FastEthernetverbindung (100MBit/sec). FastEthernetPHYs sind auch recht ueberschaubar was Preis und Funktion angeht. Stromversorgung geht auch standardisiert ueber das Ethernetkabel. 30m haut auch hin. Fuer's unkomprimierte Audio ueber Ethernet gibts auch div. Standards. Was will man mehr? Gruss WK
Matthias S. schrieb: > I2S unterstützt von sich aus aber erstmal nur 2 Kanäle, umgeschaltet > durch die WClk. Du musst dir also überlegen, wie du acht Words mit einem > WClk umschalten willst. Hallo Matthias, genau, es wird ja mit dem WS linker und rechter Kanal umgeschaltet, also normalerweise zwei Mikrofone. Da ich jetzt acht Mikrofone habe müssen die Signale schneller übertragen werden und es werden mit jedem Kanal vier Mikrofonsignale hintereinander übertragen. Ich hatte zu der ersten Lösung noch vergessen zu sagen, dass die Daten dann natürlich differenziell übertragen werden. Gruß Thorsten
Dergute W. schrieb: > Fuer's unkomprimierte Audio ueber Ethernet gibts auch div. Standards. > Was will man mehr? Hallo WK, aber bekomme ich das ganze dann noch synchron? Immerhin gibt es wie gesagt von den "Inseln" dann mehrere parallel, die alle zeitgleich ausgewertet werden müssen. Wenn ich nun vier davon am laufen habe und alles an einer Stelle ausgewertet wird, muss ich ja von dort aus alles mit meinem Takt synchronisieren, sonst habe ich ein Versatz in meinen Signalen und das darf nicht sein. Das heißt es gibt dann wiederum einen Sternpunkt, der den Takt vorgibt und an dem alle Daten von vielen Mikrofonen ankommen. Danke soweit und Gruß Thorsten
Moin, Thorsten D. schrieb: > und diese über einen langen "Tunnel" Thorsten D. schrieb: > Immerhin gibt > es wie gesagt von den "Inseln" dann mehrere parallel Hm - also 2 Inseln, die mit einem langen Tunnel verbunden sind? Mehr als 2 Inseln? Mehrere Tunnel? Oder eine Insel mit 2 Bergen und dem tiefen tiefen Tal? Aber egal. Auch fuer mehrdimensionale Inseltunneldatenautobahnen gibts da was. Wird dann halt aufwendiger. Guggstu AES67, ST-2110, mit PTP und GrandMasterClock in den jeweiligen Geschmacksrichtungen fuer die Synchronitaet...Das sollte keinen Wunsch mehr offenlassen. Sollte aber auch simpler gehen. Gruss WK
:
Bearbeitet durch User
Angehängte Dateien:
Dergute W. schrieb: > Hm - also 2 Inseln, die mit einem langen Tunnel verbunden sind? Mehr als > 2 Inseln? Mehrere Tunnel? Oder eine Insel mit 2 Bergen und dem tiefen > tiefen Tal? Okay ich gebe zu das ist etwas unübersichtlich geworden ^^. Mit Bergen hat es leider nicht viel zu tun aber ein Bild sagt ja mehr als tausend Worte. Aber es kommt jetzt doch nur eine technische Zeichnung ;) Edit: Ich hatte unten das I2S vergessen. Danke und Gruß Thorsten
:
Bearbeitet durch User
Vielleicht trifft es nicht genau dein Thema, vielleicht kommst du aber darüber weiter: Im Videobereich gibt es HD-SDI, das ist digitale Videoübertragung über normale Koax-Leitung. Ein schon recht alter Studio-Standard, der dieser Tage aber durch die Verwendung in low-budget Überwachungskameras eine starke Verbreitung erfährt. Es handelt sich um unkomprimierte Übertragung mit sehr niedriger Latenz. https://de.wikipedia.org/wiki/Serial_Digital_Interface Jedenfalls sind die HD-SDI SerDes für FPGAs wohl recht einfach gestrickt und erhältlich (kann dir aber nicht sagen wo, einfach mal den üblichen Verdächtigen nachfragen). HD-SDI kann laut obigen Link das hier: >Digitale Audio Daten nach den Standard AES-3. >Dabei können bis zu 16 unkomprimierte Audiokanäle sowohl >bei SD-SDI als auch HD-SDI eingefügt werden, deren Verfahren >in SMPTE 272M und SMPTE 299M festgelegt sind Vielleicht passt das schon zur Aufgabenstellung, vielleicht kann man den unbenötigten Videoteil in der Übertragung auch stutzen. Man hätte zumindest schon mal einen Ansatzpunkt. Vielleicht. Koax-Leitung kann man natürlich auch schön wasserdicht bekommen.
:
Bearbeitet durch User
Hallo Harald, vielen Dank für deine Antwort! Das werde ich mir mal genauer ansehen. Gruß Thorsten
Moin, Beim SDI fallen mir spontan diese "Features" ein: * Kein Standard fuer Versorgungsspannung auf der Leitung. * Unidirektional, d.h. keine Moeglichkeit irgendwelche Master-Clock oder Syncsignale zu verteilen. * SD-SDI wird man zwar recht billig senden koennen, aber zum Empfang brauchts bei 30m wahrscheinlich zwingend einen Equalizer - und die sind unangenehm teuer, weil "broffeschnl video". Letztlich ist in jedem Ethernet-Phy aehnliche Technik, sogar mehrkanalig integriert, nur gibts die da halt fast fuer umme, weil "Massenprodukt". * Die Eingaenge/Ausgaenge haben keine Trafos, dafuer gemeinsame Masse... Gruss WK
Dergute W. schrieb: > * Kein Standard fuer Versorgungsspannung auf der Leitung. Daher der Verweis auf Low-Budget Ü-Kameras, da wirds gemacht, Standard? > * Unidirektional, d.h. keine Moeglichkeit irgendwelche Master-Clock oder > Syncsignale zu verteilen. Stimmt, nur einfache Rückkanäle für Kamerasteuerung sind üblich. > * SD-SDI wird man zwar recht billig senden koennen, aber zum Empfang > brauchts bei 30m wahrscheinlich zwingend einen Equalizer - und die sind > unangenehm teuer, weil "broffeschnl video". Dann würde es nicht im o.g. Bereich Verwendung finden. Letztlich ist in jedem > Ethernet-Phy aehnliche Technik, sogar mehrkanalig integriert, nur gibts > die da halt fast fuer umme, weil "Massenprodukt". Wenn er es im Rahmen seiner Arbeit umsetzen kann, sicherlich die bevorzugende Lösung. > * Die Eingaenge/Ausgaenge haben keine Trafos, dafuer gemeinsame Masse. Sollte bei o.g. Speisung kein Problem darstellen Ich will HD-SDI um Himmels Willen nicht als beste Lösung verkaufen, dafür ist es zu fremd. Aber vielleicht bekommt er durch das Anlesen Impulse für seine Arbeit. Mehr nicht.
Schau Dir mal ADAT an. Das scheint für Deine Aufgabenstellung zu passen. https://focusrite.de/adat ADAT ist in der Profiwelt durchaus verbreitet. fchk
ADAT im Standardformat kann aber nur 48kHz x 8 und ist auch nicht für 30m geeignet. Wenn es nur ums Übertragen geht, nimmt man 4 I2S-S/PDIF-Konverter und geht über AES/EBU. Ich habe mit eigener Dekodierung im FPGA über AES mit 422 schon 384kHz elektrisch über 20m geschafft. Egon N. schrieb: > Mit FPGA nur so um sich werfen, ich glaubs nicht... Irgendwie muss der I2S ja in ein serielles Format mit eingebackenem Takt verwandelt werden. Grundsätzlich ginge natürlich HDMI 2.0, das kann 8x192kHz Audio. Das Problem dabei ist die Synchronisation: Wenn alle 4 Quellen ihren eigenen Takt haben, kann man das nicht so einfach in einen Kanal packen.
Moin, Harald A. schrieb: > Dann würde es nicht im o.g. Bereich Verwendung finden. Wenn du oder sonstwer einen guenstigen SDI Receiver Chip weiss, immer her damit. Hab' grad mal geguckt; der TW6874, ein 4fach SDI Receiver ist schon wieder EOL (1. Puhh, ueber dessen Einsatz hatt' ich schon mal nachgedacht... 2. Ach du Kagge, Intersil heisst jetzt Renesas) - ich mein', der war so um die EUR/USD 30.-- Im Vergleich zu den Apothekenpreisen von Semtech richtig guenstig. Fuer die Aufgabe hier waere der aber eh' ungeeignet gewesen (Nur 1x AudioOut iirc). Jürgen S. schrieb: > Grundsätzlich ginge natürlich HDMI 2.0, Wie dick ist denn so ein 30m HDMI-2.0 taugliches Kabel? Finger-, Arm- oder Beindick? Sauerstoffarmes Kupfer, bei Neumond von einer (maennlichen) Jungfrau gesponnen? :-) Gruss WK
Dergute W. schrieb: > Moin, > > Harald A. schrieb: >> Dann würde es nicht im o.g. Bereich Verwendung finden. > > Wenn du oder sonstwer einen guenstigen SDI Receiver Chip weiss, immer > her damit. In USA/Europa stößt man schnell auf die TI Prdukte wie den LMH0344, kostet allerdings auch 10..12€ In Produkten wie diesen hier für 167€ netto https://www.kamera-ueberwachung.de/recorder/hd-sdi-recorder/22711/hd-sdi-recorder-dvr-4kanal-h264-lan-vga-hdmi-rs485.html stecken asiastische Chipsätze drin. Bei mir ist das auch schon 2 Jahre her, der Markt ist aber stark in Bewegung. Müsste man aktuell schauen.
:
Bearbeitet durch User
Ich sage schon mal vielen Dank für die ganzen Antworten. Dann werde ich mal weiter recherchieren. Gruß Thorsten
Thorsten D. schrieb: > aber bekomme ich das ganze dann noch synchron? ohne einen gemeinsamen Haustakt an der Quelle (Mikrofone) eigentlich gar nicht. Spätestens die "Buswertung" muss die Samples 'gleichzeitig' simulieren d.h. bspw. alle Kanäle 'oversamplen (ließt sich wohl merkwürdig) und jeweils einen mit einen berechneten Wert weiter rechnen. Ob das nun vorher in den 'Sammelstellen' oder erst in "Buswertung" passiert ist bei grob ähnlicher Leistungsfähigkeit der Hardware ziemlich sicher egal. Falls (etwas spielerisch) die "Buswertung" massive KI zur Rekonstruktion der 'wahren' Samples hat und du einen gelangweilten E-Technik-Studenten kennst, dann könnte physikalisch 100mbit Ethernet 2*senden (4 Adern) mit selbststudierter Symboltabelle auch praktisch 500mbit schaffen und die 3 *8 Datenleitungen samplen und auf der anderen Seite als 3*8 Datenleitungen praktisch original wiedergeben, also 24-Kanal Logiktransferer (bei 500mbit grob bis 10MHZ) Vorteil: sehr kompatibel Nachteil: etwas wahnsinnig Eine andere Option 'fertige' Samples zu versenden und mit einer relativen Latenzkennung zu versehen und am Ende wieder zeitlich rekonstruieren, sodass eine gesamt feste Latenz von ca.4 Samples herauskommt, also praktisch Chaos um jeden Preis, ist wohl auch nicht viel sinnvoller. Die Umrechnung auf einen Takt am frühestmöglichen Punkt, wenn schon die Mikrofone ausscheiden, dürfte die praktikabelste Methode sein, aber aus Spass oder so genannten vorgeschobenen Lerngründen kann mensch die anderen auch andenken.
Wieso setzt du nicht ein rs485 full duplex tranceiver (maxim 100mbps 300mt cat5) hinter deinem FPGA? 192kbps 32bit 16 ,passt doch.
Dergute W. schrieb: > Wie dick ist denn so ein 30m HDMI-2.0 taugliches Kabel? Finger-, Arm- > oder Beindick? Sauerstoffarmes Kupfer, bei Neumond von einer > (maennlichen) Jungfrau gesponnen? :-) Ich habe hier ein 15m langes HDMI-Kabel von Sony rumliegen, das perfekt funktioniert. Dein Einwurf ist natürlich trotzdem berechtigt. Beliebig geht das nicht, jedenfalls nicht, ohne Repeater, was aber auch kein Problem wäre. Ich habe einen Ligawo-Switch am Laufen, wo Ich mit 2 10m Kabeln in einen anderen Raum komme. Wie Ich aber oben schon angemerkt hatte, dürfte der TE eher ein Problem mit den Quellen haben. Die müssten ersten mal gesynched oder resampelt werden, um sie in einer Taktdomäne gemeinsam übertragen zu können.
Um reines Audio über lange Strecken zu übertragen ist AES eigentlich perfekt. AES Transmitter Chips gibt es fast ausschließlich nur mit I2S Interface, so dass du die direkt mit einem ADC koppeln kannst und theoretisch keinen separaten Chip benötigst.
Stephan C. schrieb: > Um reines Audio über lange Strecken zu übertragen ist AES > eigentlich > perfekt. AES Transmitter Chips gibt es fast ausschließlich nur mit I2S > Interface, so dass du die direkt mit einem ADC koppeln kannst und > theoretisch keinen separaten Chip benötigst. Er will aber nichts fertiges. Er will das Rad neu erfinden.
@Egon: gib doch BITTE mal einen Link auf ein Produkt, welches du im Sinn hast.
Egon N. schrieb: > Er will aber nichts fertiges. Er will das Rad neu erfinden. Bis zu einem gewissen Grad ist das für das Vorhaben, nämlich eine Abschlussarbeit, auch zulässig, denke Ich. Kaufen und Einbauen qualifiziert ihn jedenfalls nicht.
Vielleicht mal bei Audio over Ethernet nachschauen. https://en.wikipedia.org/wiki/Audio_over_Ethernet Gruß Illi
AoIP ist ein ziemlicher Aufwand, wenn man die Eigenschaften von analog-Kabel bzw. SPDIF (geringe Latenz und absolute Samplesynchronität) nachbauen will. Nicht umsonst ist das erst in den letzten 4 Jahren so richtig in Fahrt gekommen. Da gibts jedenfalls diverse Fallstricke... Mich wundert aber, dass hier noch keiner MADI genannt hat (AFAIK AES10). Das ist richtiges Mehrkanal-Audio mit SPDIF-Payload, und zwar nicht so homöopathisch wie das semiprofessionelle ADAT, sondern gleich richtiger "Multicore-Ersatz" mit 56-64 Kanälen. Das Zeug ist aus den späten 90ern und daher inzwischen recht einfach mit FPGA zu machen. Der Vorteil wäre, dass man als Gegenstelle zB. einen PC mit MADI-Karte nehmen könnte. Leider ist MADI-Equipment aufgrund des "professionellen" Einsatzzwecks immer noch erstaunlich teuer, obwohl das technisch gesehen mit schnarchigen 125Mbit/s Rohdatenrate eigentlich eher harmlos ist. Aber für das Verpacken von I2S wäre es genau das Richtige.
Hallo Leute, ich danke euch sehr für die ganzen Hinweise! Ich werde mir das ein oder andere sicherlich genauer ansehen. Es sind viele Begriffe gefallen, die mir bis dato noch gar nichts gesagt haben. Dadurch kann ich mich gut inspirieren lassen. Dafür war meine Anfrage auch gedacht, also noch mal ein großes Danke. @Egon: Vielleicht hast du ja meine Antwort auf deine erste Nachricht nicht gelesen. Ich danke Dir auf jeden Fall auch für deine hilfreichen Beiträge. Viele Grüße Thorsten
Thorsten D. schrieb: > ich danke euch sehr für die ganzen Hinweise! Wenn du wirklich keine konkrete Antwort haben wolltest, sondern dich nur gut von fallenden Begriffen, die dir vorher nichts gesagt haben, inspirieren lassen wolltest, dann ist so eine Menge an Hinweisen natürlich sehr viel. Alle Hinweise (Jürgens teilweise sogar sehr deutlich) haben den Punkt _gemeinsamer_ Takt entweder vertuscht oder explizit gemeinsam. Ein "diverser Fallstrick" wenn sich 56-64 digitale Kanäle ähnlich anfühlen wie 28*2-32*2 und damit eine nochmalige Verpackung von 2 digitalen Kanälen (bsp. SPDIF) stricken lassen, ist dann eine der Fallen. SPFIF: 2 Känale, ein Takt MADI : 64 Känäle, ein Takt bei AoIP ist daneben noch eine standardisierte "Wordclock"(Bezeichnung aus AoIP) bzw. "Taktdomäne" (Bezeichnung von Jürgen) bzw. "Haustakt"(Bezeichnung von Dirk) Verteilung im Standard, aber der Punkt - ein Takt - ist natürlich auch bei AoIP fest. Grob unterscheiden sich die Hinweise: rs485: ist am einfachsten, wenn keine weiteres Zusammenspiel mit anderen Produkten wichtig ist AoIP: kann Switche etc. nutzen MADI, ADAT: existierende Analog/SPDIF Konverter; ein I2S-Sampler könnte interessant sein (einfach verpacken geht natürlich nicht) nur im Maß der Kompatibilität zu anderen Produkten.
Es gibt auch noch Dante. Das ist aber auch nicht gerade günstig. Da kannst du z.B. 64x64 Kanäle über eine Gigabit-Ethernet-Verbindung schicken: https://audinate.com/products/manufacturer-products/dante-brooklyn-ii Ein anderes Produkt schafft wohl sogar 512x512 Kanäle: https://audinate.com/products/manufacturer-products/dante-hc
Stephan C. schrieb: > Es gibt auch noch Dante. Das ist auch nur eine proprietäre Variante von AoIP vs. Ravenna/AES67. Im grossen und ganzen landet man immer irgendwie bei was RTP-ähnlichem und die Kunst ist, wie man das ganze schlabbrige Netzwerkzeug sample-synchron bekommt. PTP/IEEE1588 kann zwar fast jede neue PC-Netzwerkkarte, aber (AFAIK) keine Soundkarte kann sich direkt darauf synchronisieren (wenn man keinen SW-Resampler will). Also muss man aus dem PTP mit einem eigenen MAC einen realen HW-Takt basteln, da wirds dann spassig...
DANTE, AES67, AVB...geht alles. Für DANTE brauchst du aber ein Lizenz und die reden nicht mit jedem "small potatoe" oder Bastler ... Für AVB gibt es Demo Platinen und es ist offener Standard. Schau mal bei XMOS. AES67 ist offen, gibt da auch fertige Demoplatinen zum Beispiel von archwave.net Und die sind dort deutlich zugänglicher als die Audinate Leute mit DANTE.
Georg A. schrieb: > Im grossen und ganzen landet man immer irgendwie bei was RTP-ähnlichem > und die Kunst ist, wie man das ganze schlabbrige Netzwerkzeug > sample-synchron bekommt. das ist vermutlich eine der gewünschten Kunst-Inspirationen für den Kunststudiengang E-Technik des TO. Schlabbriges Netzwerkzeugs das nicht mehr unnötig programmiert werden muss und den man irgendwie bei was RTF-ähnlichem landen lässt. Wenn der Verpackungskünstler Georg A. schrieb: > [Madi:] 'Aber' für das Verpacken > von I2S wäre es genau das Richtige. anstelle der aber-Kunst versucht hätte zwei(2) asynchrone I2C in ein (1) SPDIF_2k zu verpacken, dann könnte der Künstler lernen, dass auch eine Verpackung in Madi_64k die gleiche Problematik hat. > PTP/IEEE1588 kann zwar fast jede neue PC-Netzwerkkarte, aber (AFAIK) > keine Soundkarte kann sich direkt darauf synchronisieren da ist dann aber schon etwas mehr schief gelaufen wenn Soundkarten die sich eigenständig direkt mit Netzwerkkarten oder etwas anderem aus der Umwelt synchronisieren imaginiert werden und einfachste Realität als "aber" gefühlt wird. > wenn man keinen SW-Resampler will passt i.A. gar keine Soundkarte mit mehreren Kanälen, sondern ein Analog-Mischer Die technische Kunst zuerst zwei(2) asynchrone I2C Kanäle denken zu können und erst danach über Massenkanäle zu philosophieren, beherrscht die junge Künstlergeneration die Masse als Inspiration aller Fragestellungen ausgibt sicherlich nicht. Die Angst vor einer Einzahl (ein Takt) lässt dann Soundkarten die sich selbständig auf etwas synchronisieren zur gefühlten Realität werden.
Beitrag #5340795 wurde von einem Moderator gelöscht.
So krass wollte ich es nicht ausdrücken, aber es wäre schön, wenn Dirk mal einen PRAKTISCHEN Vorschlag macht, wie denn nun weitergeht. Sich in praxisfernen Taktgalaxien wegzuträumen ist ja leider am Ende des Tages nichts, was man als Arbeitsergebnis präsentieren könnte.
Mann, Mann, Mann jetzt wurscheln hier schon Philosphen und Künstler in der Diskussion mit. Was ist denn bitte so schwierig daran, einen lumpigen Audiodatenpfad einzupacken? Sampeln, TimeStamp drauf und gut ist! Das geht analog wie digital. Wenn man eine brüchige Verbindung wie Ethernet hat, muss man eben puffern. >Samplegenau Heißt genau was? Zu dem Zeitpunkt des Entstehens des samples kriegst Du es auf keiner Leitung hinten wieder raus. Hat immer Delay. Nimmt man das in Kauf, ist es nur eine Frage der Puffergrösse. >MADI Dazu stelle Ich folgende Frage: Hat innerhalb des MADI Protokolls jeder Kanal einen eigenen Takt oder laufen die Daten alle synchron? Wahrscheinlich gilt Vermutung 2 und dann kann man das schon wegwerfen. Oder aber, der TO lässt sich dazu herab, darüber nachzudenken, ob seine Quellen synchron sind und damit nur eine echte Datenquelle darstellen. Dann geht es sehr einfach. Das Zauberwort nennt sich Multiplexer. 2x4 Kanal 48kHz Audio = 192kHz x 24Bit = unter 5Mbps. Das ging mit Ethernet schon vor 15 Jahren. Vielleicht möchte der TO aber auch USB 1.0 bauen? Mit der heutigen Technik sind da sicher 50m möglich. Käme auf einen Test an.
Markus W. schrieb: >>Samplegenau > Heißt genau was? Dass jedes Sample einen (impliziten/expliziten) Zeitstempel hat, mit dem man andere gleich-zeitige Samples dann finden und verarbeiten (zB. mischen) kann. Da gehts nicht um die Verzögerung, die hat man immer irgendwo. Bei MADI geht das quasi von selbst, weil alle Kanäle auf demselben (potentiell extern zugeführten) Wordclock basieren und damit alle Samples eines Frames vom selben Zeitpunkt stammen. Bei Netzwerk ist das nicht mehr ganz trivial. Die Quellen müssen ihren (hoffentlich global per PTP synchronisierten) Zeitstempel für bestimmte Samplenummern in den Paketen mitsenden, eine Senke muss sich dann zB. zum Mischen alle Samples mit demselben Zeitstempel zusammensuchen. Ich sags ja nur, weil hier so locker-flockig AoIP eingeworfen wurde...
Beitrag #5341513 wurde von einem Moderator gelöscht.
Beitrag #5341666 wurde von einem Moderator gelöscht.
Hallo zusammen, MADI scheint von den Anforderungen her schon mal nicht verkehrt zu sein: Viele Kanäle, 48kHz, 24bit, 100m... Allerdings kommt man an die Schnittstelle oder das Protokoll nicht ohne weiteres dran. Zumindest an die AES10 Spezifikationen komme ich nicht ohne Gebühr dran, was grundsetzlich ja kein Problem ist, ich mich aber erstmal nur informieren möchte. Entsprechende Hardware beginnt interessanter Weise bei 900 Euro aufwärts, ich suche eher etwas Richtung ICs/ Bauteile um selbst etwas umzusetzen.. Bei ADAT sieht es ganz ähnlich aus für mich. 8 Kanäle, 24bit, 48kHz aber leider nur bis 20 Meter ca. da über Toslink. Da wäre es interessant ob man das Signal nicht umwandeln kann in ein differentiell übertragbares mit entsprechendem Treiber (Richtung LVDS) oder über Glasfaser versenden kann. Was die Schnittstelle angeht habe ich auch dort leider nicht viel gefunden, außer sehr teure Peripherie. Wo ich im Moment stark am hinterhergucken bin sind die Serializer/ Deserializer (SerDes) die ebenfalls scheinbar meinen Anforderungen entsprechen (8 Kanal I2S über eine (Doppel-)Leitung). Gefunden habe ich da den DS90UA101-Q1 und den Bruder DS90UA102-Q1 von TI bei denen eine Kabellänge von 15 Metern angegeben ist und die MAX920X Familie (MAX9205/6/7/8) von Maxim I., die bis 30 Meter (meine Mindestanforderung) getestet wurden. Mich hat jetzt z.B interessiert warum nur 15m, ob es am Treiber liegt, dass der nicht genug drückt, oder am Protokoll usw. /*Edit: und ob man das Signal dann auch über Glasfaser übertragen könnte.*/ Ich meine es wird ja auch differentiell übertragen und über Ethernet sind ja auch 100m möglich. Ich habe bei den Herstellern auch mal nachgefragt was die mir dazu sagen können. Ansonsten würde ich mir das wohl auch selbst basteln mit FPGA mittels Multiplexern und entsprechenden Abtastraten und was man noch so braucht (input latch? encoder?) und einem Treiber für die differentielle Übertragung (LVDS?). Ich weiß nur nicht bei welcher Länge ich dann landen werde und ob es am Ende noch auf das Protokoll ankommt, denn damit habe ich noch nicht viel Erfahrung. Es wäre nett, wenn Ihr mir noch mal eure Gedanken zu meine Überlegungen äußern würdet. Vielen Dank und viele Grüße Thorsten
:
Bearbeitet durch User
Ich würde dir nochmal AES3 ans Herz legen. Da kannst du ebenfalls 8 Kanäle über ein RJ45-Kabel übertragen.
Moin, OK, zu allererst und wichtigst: Was muss dieses "Projekt" fuer dich leisten? Das ist schonmal entscheidend. Wenn du am Anfang schreibst: Thorsten D. schrieb: > ich bin vor dem Abschluss meines E-Technik-Studiums und wollte mir ein > paar Meinungen über eine Aufgabenstellung einholen. koennte man auf die Idee kommen, dass du da was als Diplom/Bachelor/Master/wasweissich-Arbeit in der Richtung machen willst. Grosse Warnung: Das wird nix. Ist viel zu umfangreich. Da machst du dir Stress ohne Ende und am Schluss stehst du arg bedroeppelt da, weil irgendein Furz nicht auf Anhieb geht, die Zeit zu Ende ist, du nix vorweisen kannst und dann die krampfhafte Suche losgeht, wie man aus dem Haufen rauchender Truemmer noch irgendwie eine "wissenschaftliche Arbeit" zaubern kann. Geschweige denn, wie man die noch auf 'ne anstaendige Note bringen kann. Ich wuerd' sagen: Da ist alleine die Analyse von Standards, die es fuer sowas gibt, und was man nun genau braucht, und was man deshalb nehmen kann, schon eine komplette Arbeit fuer sich. Aufbau der HW eine weitere Arbeit (nur fuer Leute geeignet, die schon vor dem Studium einschlaegige HW-Bastelerfahrungen gemacht haben); dann noch die noetige Software fuer die FPGAs auch noch mindestens eine weitere Arbeit. Ich nehm' dir sofort ab, dass du da jetzt monstermaessig motiviert bist, und am liebsten sofort Kaefer auf Platinen loeten willst und messen/testen bis der Arzt kommt. Mach' das nicht, wenns um irgendwelche Noten geht. Privat oder als Hiwi-Stelle wird's OK sein, weil da vom Erfolg und Misserfolg kein Endzeugnis abhaengt. Wenns unbedingt doch eine benotete Arbeit werden muss, dann guck', dass du den Umfang mit deinem Betreuer ganz klar definierst und stark reduzierst. Zum technischen: Ueberleg' dir erstmal, wie das mit der Synchronitaet und Referenztakt der verschiedenen Audios sein muss, und was du an Delay vertragen kannst. Ist ja die Frage, welche Signale du in welche Richtungen uebertragen musst. Ansonsten bleib' ich dabei: Fuer die unteren Layer bei deinen Anforderungen ist Ethernet das Mittel der Wahl. Weil du dich da "ganz unten" um nix kuemmern musst. Kleines Beispiel: Weisst du, was du fuer ein Kabel nehmen musst, um deine SerDes Verbindung darueber laufen lassen zu koennen? Im Datenblatt des Max9206 kommt das Wort "Equalizer" nicht vor. Also wird wohl keiner drinnensein...Brauchst du dann einen extra? - hoechstwahrscheinlich nach 30m besserem Klingeldraht. Ist der TI-Baustein besser; der hat anscheindend einen drinnen. Aber geht der so out-of-the-box? Fuer welches Kabel, welche Laengen? Was brauchst du an Schutzschaltungen, dass dir deine teuren SerDes oder auch ggf. irgendwelche RS-485 Transceiver nicht um die Ohren fliegen, wenn ueber den Schutzleiter oder sonstwie irgendwelche Potentialunterschiede, die innerhalb von 30m schonmal auftreten koennen, ueber die Leitung geistern? Dagegen Ethernet: * Die Trafos machen's potentialausgleichsmaessig idiotensicher. * Jeder Depp in China kann dir ein 30m Ethernetkabel verkaufen. Und das funktioniert dann auch noch. In allen Farben. Und kosta fast ganix. * Jeder Ethernetphy fuer ein paar ct. hat einen kompletten DSP drinnen, der Cable equalizer, Echo-cancelling, und noch so einiges mehr komplett automatisch macht. Wo sicher ist, dass man sich nicht drum kuemmern muss. Es geht einfach. Stecker rein, Linkpulse kommen, Link wird zwischen den Partnern ausgehandelt, Verbindung steht, LEDs am RJ45 gehen an; fertsch. Ohne dass du ein Bit programmieren musstest. Und das ist nur ein kleiner Ausschnitt von ein paar Problemen aufm Layer0. Gruss WK
Beitrag #5342837 wurde von einem Moderator gelöscht.
Dergute W. schrieb: > Wenns unbedingt doch eine benotete Arbeit werden muss, dann guck', dass > du den Umfang mit deinem Betreuer ganz klar definierst und stark > reduzierst. Das würde ich auch sagen. 4 FPGAs, um wie im Bild beschrieben, die I2S anzunehmen, ist ganz sicher eine Lösung, die eine Note 4 oder 5 nach sich ziehen wird. Das geht mit einem einzigen Baustein. Wenn mir jemand DAS Konzept vorlegen würde, gäbe es schon das erste Minus. Die Herausforderung besteht einfach nur darin, die Signale zu korrellieren, wenn die I2S-Geräte am Eingang ihr Eigenleben haben. Georg A. schrieb: > Bei MADI geht das quasi von selbst, weil alle Kanäle auf demselben > (potentiell extern zugeführten) Wordclock basieren und damit alle > Samples eines Frames vom selben Zeitpunkt stammen. Soweit die Theorie, wenn es möglich ist, den Mikrofon-Wandlern den Master-Clok vorzugeben. Das ist aber nicht ausdrücklich so benannt. In den meisten Anwendungen arbeiten die völlig autark, nicht mal notwendigerweise auf derselben Samplefrequenz! Es muss also resampelt werden, um auf den gleichen MADI-Takt zu kommen. Wir arbeiten mit einem asynchronen oversampler-Baustein, der mit 12 MHz gefahren wird und das I2S- (LR und Daten) gesampelt überträgt. Die müssen dann hinten rückinterpretiert werden. Dafür gibt es aber auch passende Gegenstellen. Preis für die Lösung: unter 100 Euro inklusive der beiden Transceiver und 2 kleiner Spartan-FPGAs.
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.