MADI stirbt - Trend auf der IBC

A

Adebar

Registriert
25.08.09
Beiträge
933
Reaktionen
250
Punkte
1.695
Auf der diesjährigen IBC war eines deutlich. MADI stirbt langsam. Fast auf allen Ständen, wo es um die Übertragung mehrerer Kanäle gleichzeitig ging, hat man auf Audio over IP gesetzt.

Als Beispiel sei Ravenna genannt
http://en.wikipedia.org/wiki/Ravenna_(networking)

Es gibt aber noch viele andere Lösungen dazu. Die Vorteile liegen auf der Hand. Diese Systeme sind leistungsfähiger als MADI und billiger. Die Halbierung der Kanalzahl bei Verdopplung der Samplingfrequenz ist bei MADI ein Problem. So was gibt es nur noch bei Adat und zwingt bei Produktionen nit Samplingfrequnzen > 48k zu Klimmzügen.

Bin mal gespannt, welches System das Rennen macht und hoffe, es werden nicht wieder viele Parallel-Standards.
 
Nun, das halte ich nicht unbedingt für einen Fortschritt. Nungut, MADI hat schon einige Jahrzehnte auf dem Puckel. Wenn ich mich korrekt erinnere, so wurde das von AMS Neve für das Capricorn Pult entwickelt.
Audio over IP ist ja ganz nett und billig, aber weder IP, noch Ethernet sind für Echtzeitanwendungen entwickelt. Man muss da doch einiges unternehmen um Jitter zu kompensieren. Und damit holt man sich dann vermutlich auch ordentlich Latenzen rein. Paketorientierte Netze sind einfach suboptimal für Streams.
 
Das stimmt schon, deswegen ist ja auch Firewire theoretisch besser als USB - nicht bezüglich Datenrate, sondern bezüglich des Protokolls.

Aber bei USB hat man das ja im Griff und Audio over IP wird das wohl auch schaffen. Unsicherheiten bleiben schon, gebe ich Dir Recht. Bezüglich Jitter mache ich mir da am wenigsten Sorgen. Die Taktung muss da eh anders laufen, z.B. über WC.

Interessant ist, wie es sich mit Latenzen verhält. Doch gerade da, wo das ein Thema ist, Monitoring im Livebereich, ist Audio over IP sehr verbreitet. Fast jedes digitale Beschallungspult der mittleren Preisklasse aufwärts bietet heute so was per CAT5 oder Fiber Cable. Auch da ist MADI auf dem Rückzug.
 
MADI war für mich gedanklich nie eine lösung die auf das thema komplett den deckel drauf macht, aber audio over ethernet klingt wie ein traum. so könnte man sicher stellen das *alles* auch 100%ig (ala TCP mit ACK/NACK) und dazu noch ohne jitter ankommt, da jedes paket ja eine indeutige sequenznummer hat. dann brauchts auch keine wordclock mehr. und die daten könnten auch beliebig zwischen verschiedenen geräten geroutet & gesplittet werden, mit nur einem kabel.
 
Das stimmt schon, deswegen ist ja auch Firewire theoretisch besser als USB - nicht bezüglich Datenrate, sondern bezüglich des Protokolls.

Aber bei USB hat man das ja im Griff und Audio over IP wird das wohl auch schaffen. Unsicherheiten bleiben schon, gebe ich Dir Recht. Bezüglich Jitter mache ich mir da am wenigsten Sorgen. Die Taktung muss da eh anders laufen, z.B. über WC.

Jitter bereitet schon Probleme. Bei IP ist nicht sichergestellt, das das Paket, welches als erstes gesendet wurde, auch als erstes eintrifft. Gut, man wird solche Audio-over-IP Konstruktionen nicht über Router und WAN laufen lassen, sondern in einem eigenen Netz, wo tunlichst kein anderer Traffic drauf ist und benutzt mindestens Gigabit.

Interessant ist, wie es sich mit Latenzen verhält. Doch gerade da, wo das ein Thema ist, Monitoring im Livebereich, ist Audio over IP sehr verbreitet. Fast jedes digitale Beschallungspult der mittleren Preisklasse aufwärts bietet heute so was per CAT5 oder Fiber Cable. Auch da ist MADI auf dem Rückzug.

Hast Du mal Beispiele dafür? Ich habe z.B. mal bei DiGiCo geschaut und dort steht z.B.

[qoute]As standard, the SD5 comes with a 2Gb fibre optic system, which is capable of running 448 channels of I/O at 96kHz, plus 56 console-to-console tie lines, allowing connection to up to 14 of the SD-Series racks. [/quote]

Das bedeutet aber nicht zwangsläufig Audio-over-IP, sondern hört sich eher nach einer properitären Lösung an. Leider finde ich keine genaueren Info dazu. Das natürlich einige Konsolen Audio-over-IP anbieten ist klar: Es ist nun mal ein sehr billiges(Im Sinne von einfach zu realisieren) Feature. Aber ob das auch wirklich für Live-Monitoring taugt, ist eine andere Sache.

Aber längst nicht alles, was über Cat5 oder Fibre läuft, ist auch IP.
 
MADI war für mich gedanklich nie eine lösung die auf das thema komplett den deckel drauf macht, aber audio over ethernet klingt wie ein traum. so könnte man sicher stellen das *alles* auch 100%ig (ala TCP mit ACK/NACK) und dazu noch ohne jitter ankommt, da jedes paket ja eine indeutige sequenznummer hat. dann brauchts auch keine wordclock mehr. und die daten könnten auch beliebig zwischen verschiedenen geräten geroutet & gesplittet werden, mit nur einem kabel.

Ein Traum schon, sicherlich auch z.B. für Broadcast genial. Aber für Live und Studio nicht optimal. TCP kostet Zeit und das Umsortieren von Paketen braucht auch noch mal einiges an Zeit. Nicht umsonst werden eigentlich sämtliche Streaming-Geschichten per UDP gemacht. Bei Telefonie oder Fernsehen ist es nicht so schlimm, wenn mal Pakete verloren gehen. Für professionelles Audio in Echtzeit aber eher nicht geeignet.
Ethernet ist nun mal nicht optimal für Echtzeit-Audio-Anwendungen. Aber leider sind solche Techniken wie ATM ausgestorben. Optimal wäre daher eher SDH-Technik, so wie sie zur Zeit noch in der Vermittlungstechnik eingesetzt wird. Aber die ist leider nicht bezahlbar.
 
TCP selbst würde ich auch nicht nehmen, daher meinte ich auch "ala TCP". man müsste sich ein für audio optimiertes protokoll überlegen welches sicherstellt, dass die pakete in der richtigen reihenfolge ankommen. es sollte doch machbar sein, dass ein gigabit router pakete von verschiedenen sendern an die entsprechenden empfänger so durchreichen kann, dass es keine paketverluste gibt (gibt es bei direkter anbindung via kabel ja quasi sowieso nie) & die pakete einen eindeutigen timestamp haben (=wordclock) & das ganz in sagen wir mal unter 1ms. das wäre nun der fall mit router. wenn man 2 geräte (soundkarte + wandler) miteinander verbindet, ist das ganze ja nochmal einfacher.
 
TCP selbst würde ich auch nicht nehmen, daher meinte ich auch "ala TCP". man müsste sich ein für audio optimiertes protokoll überlegen welches sicherstellt, dass die pakete in der richtigen reihenfolge ankommen. es sollte doch machbar sein, dass ein gigabit router pakete von verschiedenen sendern an die entsprechenden empfänger so durchreichen kann, dass es keine paketverluste gibt

Wenn man vom OSI-Schichtenmodell ausgeht, gehen da einige Schichten durcheinander.

(gibt es bei direkter anbindung via kabel ja quasi sowieso nie)

Leider doch, Störungen können auch da zu Paketverlusten kommen ;-) Das einzige, was Dir bei P2P-Verbindungen erspart bleibt, sind Kollisionen.

& die pakete einen eindeutigen timestamp haben (=wordclock) & das ganz in sagen wir mal unter 1ms. das wäre nun der fall mit router. wenn man 2 geräte (soundkarte + wandler) miteinander verbindet, ist das ganze ja nochmal einfacher.

Siehst Du, jetzt bist Du genau da angelangt, worauf ich hinaus wollte: Audio-over-IP ist nicht optimal. Schau Dir mal an, wie SDH funktioniert: http://de.wikipedia.org/wiki/Synchrone_Digitale_Hierarchie. Du hast da keine Pakete, sondern einen kontinuierlichen Bitstrom. Eben genau das, was Du bei digitalem Audio auch hast. Direkt SDH zu benutzen, wäre für diese Form der Audio-Übertragung, weil Du viele Funktionen gar nicht brauchst und die Taktung ein Nachteil ist.
Aber das Beispiel SDH zeigt, was eigentlich notwendig ist. Du brauchst einen kontinuierlichen seriellen Bitstrom, in den Deine Audio Kanäle gemultiplexed werden, d.h. Du hast Container fester Größe, die in kontinuierlicher Reihenfolge gesendet werden, z.B.:
[Kanal1]|[Kanal2]|[Kanal3]|...[Kanal2048]|[Kanal1]|[Kanal2]...
Da Du keinen Wordclock haben willst, muss dann das Timing aus dem Datenstrom gewonnen werden. Das sollte sich aber durch eine geegnete Kodierung, ähnlich wie bei Ethernet, ohne Probleme erledigen lassen. Wenn man die Container universell hält, sollten sich auch parallel Daten, Midi, ... übertragen lassen, ähnlich wie es bei ATM auch ist.
Dann müsste man einen Mittelwert zwischen Containergröße und Kanalzahl ermitteln, so dass man auf eine optimale Latenz kommt.
Topologisch kann man das entweder als Ring aufbauen oder besser sternförmig mit entsprechenden Switchen. Die nehmen dann das Multiplexing vor, so dass Du einfach Kanäle ein- und auskoppeln kannst. Somit hast Du auch die Möglichkeit einen Kanal an mehrere Empfänger zu verteilen.
 
für ACKs a la TCP wird keine zeit sein wenn man die latenz gering halten will, allerdings ist das auch gar nicht notwendig wie man am beispiel RDP via UDP sieht -> hauptsache fehler werden erkannt und auch an benutzer bzw. drüberliegenden schichten kommuniziert.... in latenzunkritischen anwendungen kann man ja nochmal ein kaputtes packet neu sich senden lassen.
 
Ich verstehe davon ja nichts, aber hier wird behauptet, dass die Synchronisation kein Problem sei:

http://ravenna.alcnetworx.com/technology/technology-overview.html

klingt doch ganz gut :)

Ja schon, Synchronisation is ja auch nur bedingt das Thema. Mir geht es ja in erster Linie um die Latenz: http://ravenna.alcnetworx.com/technology/features/latency.html liest sich sehr schwammig.

Dort steht z.B.

Play-out correlation between streams - as the exact play-out time of different streams can be correlated - even across different devices in the network - latency of all affected streams needs to be increased to match the maximum latency of all related streams.

Was für mich soviel heißt wie: Wenn man verschiedene Geräte im Netz hat muss man solange herumspielen, bis die Latenz passt ;-)

Was mir fehlt, ist ein Beispiel: Also wieviele ms bei n Audiokanälen (24/96)? Dort steht nur etwas von Latenzen im sub-ms-Bereich. Das kann ich aber nicht so ganz glauben, zumindest nicht in einem geswitchten Netzwerk. Ein einfacher Ping verursacht hier schon ca. 0,4 ms (Gbit-geswitched). Wenn ich etwas mehr Traffic habe und mehr Daten, komme ich schon auf Ausreißer bis zu 4 ms. Zusammen mit den Wandlerlatenzen kommt dann da schon einiges zusammen.

Das ist mit Sicherheit Klasse, um die Signale vom FOH zu Recording-Truck zu schicken. Im Livebetrieb mag das auch noch gehen, wenn man die Signale vom Monitorplatz zum FOH schickt. Ich muss mal meinen Kumpel Olly fragen, ob die sowas schon im Einsatz haben.
 
@dryman, danke für die erläuterung. SDH klingt in der tat spannend!
 
für ACKs a la TCP wird keine zeit sein wenn man die latenz gering halten will, allerdings ist das auch gar nicht notwendig wie man am beispiel RDP via UDP sieht -> hauptsache fehler werden erkannt und auch an benutzer bzw. drüberliegenden schichten kommuniziert.... in latenzunkritischen anwendungen kann man ja nochmal ein kaputtes packet neu sich senden lassen.

Und schon hast Du TCP in UDP nachgebaut ;-)
 
für ACKs a la TCP wird keine zeit sein wenn man die latenz gering halten will, allerdings ist das auch gar nicht notwendig wie man am beispiel RDP via UDP sieht -> hauptsache fehler werden erkannt und auch an benutzer bzw. drüberliegenden schichten kommuniziert.... in latenzunkritischen anwendungen kann man ja nochmal ein kaputtes packet neu sich senden lassen.

Und schon hast Du TCP in UDP nachgebaut ;-)

eben nicht, weil ich mir bei einer guten verbindung viel (rück)traffic und timeouts erspare und für niedriglatenz-einsatz nicht protokoll wechseln muss.

diese fehlerkorrektur im sinne von TCP hat man ja jetzt auch nicht bei adat, madi... dafür hat man bei ner gigabit-verbindung durchaus reserven das signal an sich schon ziemlich robust zu gestalten. man könnte ja die fenstergröße konstant lassen und bei geringerer kanalanzahl einfach mehr übertragunssicherheit durch checksummen, redundanz usw. machen.

edit: rein rechnerisch sollten sich über ne 1GB infrastruktur ja locker >150 Kanäle bei 96kHz,24bit ausgehen inkl. viel redundanzabsicherungen.
 

Oft gelesene Themen

Zurück
Oben