Probleme mit Dante

Moin,

Zitat von "mike j."

Teilweise bekomme ich beim aktivieren des DVS Treibers einen Error 512 (Audio Driver Error) oder einen (Audio Routing Error) 1024.

Das könnte auf ein Problem der Anbindung der DVS an Deine Audio-Software hindeuten. Ich nehme an diese Aufgabe übernimmt bei Dir ASIO? Für die DVS ist ASIO Dein Rechner, ASIO kaputt = kein Rechner.

Wenn der Dante Controller auf dem Rechner die M-Dante findet ist jedenfalls die Verbindung zwischen DVS und M-Dante in Ordnung.

@ marcoboy: Du stiftest Verwirrung, warum**? UND: Warum sollte man nicht einfach den primary-Port der M-Dante >>UND SONST KEINEN<< mit dem iDR-Switch verbinden, und einen weiteren Port des iDR-Switches mit dem Recording-Rechner verbinden? Weil das funktioniert*? Der primary-Port der M-Dante kann 100Mbit, und das reicht in dem Fall!
Andersrum funktionierts nicht: RTFM!: "Release 1 does not currently support a mix of Gigabit and Fast Ethernet (100 Mbit) on its ports." Da steht "a mix"! Also keine Mischung von Gigabit-Recordingrechner, und 100Mbit für irgendwas an den Ports der M-Dante! So lässt sich der ACE-Netzwerktunnel nicht auf den Gigabit-Recordingrechner durchverbinden, WEIL der eben an einem 100Mbit-Switch-Port der iDR zur Verfügung steht! Logisch denken! RTFM!

Daß Dante kein 100Mbit kann steht nirgens, wofür auch, es kann ja!

*) So sollte auch der ACE-Tunnel bis zum Rechner funktionieren, der hängt ja intern am iDR-Switch, dort gibts den Tunnel.

**)

Zitat von &quot;marcoboy&quot;

Wenn es gar nicht klappt ich nehme die Karte !

Dummdreist

Grüße,

Bernd

Moin,

Zitat von &quot;TWOsider&quot;

Ich seh das so: Es war noch nie so günstig möglich, qualitativ hochwertige Mehrspur-Live-Aufnahmen zu machen... ...Da muss ich doch auf der gleichen Kiste nicht auch noch die Editor-Software laufen lassen, bloß "weils geht" ...

Immerhin gehts, ganz im Gegensatz zu den Berichten hier . Es war auch noch nie möglich mit so unglaublich wenig Schlepperei, so wenig Platz und relativ ohne Kabel. Und ich muß nur von einem Rechner ein Backup machen. Der Gedanke im fernen Bühnengewühle einen Laptop ungeschützt zu betreiben, ähm... Muß wohl an meinen 22 Jahren in der VA-Tontechnik liegen, daß ich die Anzahl von unprofessionellen (z.B."RJ-45", USB, VGA) Verbindungen klein halte und diese Bürotechnik nicht auf Bühnen stelle oder gar dort betreibe. Kein Musiker stellt sein Instrument an den FOH.

Anyway, es geht hier um Dante und Netzwerk, abermals vielen Dank für Deine Tipps. Ich werds berichten wenn der AP für das zusätzliche bewegliche Editor-Subnotebook läuft.

Gruß,

Bernd

wenn ich die beiträge hier so lese bin ich heilfroh, dass ich mein recording mit MADI aufgebaut habe.
anschliessen - kanäle zuweisen - geht. :wink:

ich betreibe damit übrigens einen rechner auf der bühne - und zwar fest eingebaut ins mixrack!
diesen remote ich dann vom FOH aus per laptop mit RDP oder über's iPad.
auf dem bühnenrechner kann ich auch problemlos den editor laufen lassen

Lieber Bernd ich gebe nur meine Erkenntnisse wieder und die neuste kann ich dir Mitteilen warum das eine schlechte Idee ist. Deine und meine ewt.

Da ich festgestellt habe das auf allen Ports die UDP Pakete für den Audio Flow ausgegeben werden wandern diese auch auf deine Interne IDR Switch. Das Surface hängt an einer Verbindung die eine sehr geringe Bandbreite besitzt. Der Rest der Verbindung ist durch die 100Mbit/s mit ACE 64x64 Ch ausgereizt. So werden dir nur 6Mbit/s oder weniger zum Surface bleiben. Die UDP Pakete drücken dir die Verbindung zur IDR zu. So das es sein kann (weiß jetzt nicht wie die Steuerung der IDR funktioniert) das das Mixrack auf deinen Eingriff an dem Surface nicht reagiert oder verzögert. Es kann auch möglich sein das hier QoS stattfindet.

Das tritt erst recht auf wenn das primäre Dante Netzwerk mit 1Gbit/s Arbeitet und du es durch einen anderen Port auf 100Mbit/s drosselt. Die Pakete nehmen der Art zu das sie von deiner 100Mbit/s Switch nicht mehr verarbeitet werden kann oder andere Sachen stört.

Deswegen rät A&H davon ab. Bis zu dem Zeitpunkt als ich davon ausging das auf dem Controller Port "laut Manual" keine Dante Audiodaten ausgeben werden. Wäre das von mir Empfohlene System durch aus machbar. Ist es jetzt immer noch aber man muss eben schauen was mit den UDP Pakten im Netz passiert. Besser wäre man blockt diese, warum das die Dante Karte laut Manual nicht macht weiß ich nicht.

Warum Dante keine 100Mbits Verbindung empfiehlt? Die Latenz im System steigt und bei mehr als 32x32 ch können die Pakete nicht mehr von der Switch oder Hardware verarbeitet werden. Deshalb unterstützte die Hardware in der ersten Version das erst gar nicht.

Eine Switch dazwischen muss gewisse Eigenschaften besitzen. Da die Pakete priorisiert werden müssen. Diese Eigenschaften erfüllt die Switch in der IDR nicht. Dante dort zu verteilen ist eine sehr schlechte Idee. Weil wie oben beschrieben die Pakete auch die Kommunikation der IDR stören könnten und weil diese die Eigenschaften nicht besitzt.

Deshalb bringt A&H die Anwender erst gar nicht auf solche Ideen. Was man machen kann die Pakete mit einen billigen Router die ja Firewall Funktionen auf dem WAN Port bereitstellen zu blockieren. Nur wäre das eine schlechte Idee diesen in das Dante Netzwerk zu binden. Weil dieser die Eigenschaften nicht besitzt. Oder die empfohlene Switch stellst du eben so ein das die Pakete blockiert werden auf einen Port.

TWOsider wird mir da als Netzwerkspeziallist in einigen Punkten recht geben. Meine oben genannte Idee den PC einfach eine zweite Netzwerkkarte zu verpassen wäre die wirklich beste Lösung. Zwei getrennte Netzwerke die nichts miteinander zu tun haben.

Wora Dante spielt wirklich auf Anhieb. Ich habe das mal mit einen Win7 Laptop probiert lief an Anhieb ohne aussetzen. Es scheint aber Probleme mit Hardware zu geben. Das kann dir aber mit deiner Madi Soundkarte auch passieren. Die muss man auch erstmal kaufen. Madi ist auch nicht kostengünstig zu verteilen.

Moin,

@ wora: Schon klar, kein Audio über Netzwerk - keine Audio-Netzwerkprobleme. Wobei diese Probleme hier keine Dante-Probleme sind, sondern den Mangel an strukturierter Arbeitsweise aufdecken. Diesen Mangel füllt weder MADI noch WAVES.

Ich hatte und habe kein Bedürfniss weitere 2-3 HE Shockmounted in Form eines 19" Rechners rumzuschleppen, ganz davon abgesehen Diesen aufzusetzen und zu backuppen, weil es eben funktioniert - ohne extra Switch - mit 100Mbit. Und diejenigen, die kein Problem mit einem extra-Rechner im iDR-Case haben können es genauso machen, ob da nun 1 Meter Patch, oder 100 Meter CAT7 dazwischen sind ist schließlich nicht nur Dante egal.

Wenn man allerdings DHCP für Aufgaben nutzt für die es nicht erfunden wurde, ja, schlicht überflüssig ist, und zusätzlich schlicht überflüssige Netzwerkkomponenten zusammenstöpselt - ohne davon Ahnung zu haben, und zur Manifestierung der finalen Katastrophe das f****** Manual nicht ließt... (Multicast* etc.)...

...der hat völlig vergessen, wieviel Fleißarbeit und Sorgfalt die analoge Anbindung einer 2" 24er, oder auch eines entsetzlichen ADAT-Stapels bedeutete (und wie "zuverlässig" das dann spielte).

Ich glaube auch nicht, daß Dante außergewöhnliche Probleme mit Windoof ASIO hat, auch wenn ich mit OS X und CoreAudio arbeite, obwohl... Coreaudio ist sehr mächtig, es gibt viele Player und Recorder, und es gibt JackOSX, die Patchbay für alles was im Rechner geroutet werden will.

Ich kann definitiv sagen, daß der ganze IT-Kram schneller geht als das analoge Gelöte. Aber mit einen Click geht eben nichts.

Grüße,

Bernd

*Lieber marcoboy,
schalte an Deiner iDR Multicast aus

Die Manuals geben den dringenden Rat weder bei Dante, noch bei iDR, Editor und Surface, mit Multicast zu arbeiten. Multicast bedeutet schließlich, daß die Pakete an alle am Switch angeschlossenen Empfänger gesendet werden. Die iDR quatscht dann z.B. mit den Metering-Paketen auch den Port der M-Dante zu, und stört die knappen 100Mbit dort. Außerdem würde der Port des Recording-Rechners zugequatscht, mit z.B. Metering Paketen. Multicast ist bei der iDR dazu da auch mit an der Surface angeschlossenem Editor Rechner, bei belastetem Netzwerk(Tunnel) ein schöneres Metering zu machen. Wie schlimm das ohne Multicast aussieht weiß ich nicht. Der Editor/Recording-Rechner am iDR-Switch zeigt durchgehend schönes Metering - ohne Multicast - und mit laufendem Dante incl. laufender Aufnahme.

Auch Dante sollte - ohne Multicast - vom iDR-Switch nur an dem Port ausgegeben werden, an dem der Rechner mit der DVS hängt. Dafür schickt Dante ja die Ziel IP, die IP des DVS-Rechners mit. Der kleine ACE-Tunnel hängt intern auch am iDR-Switch. ACE beschützt sich sehr wahrscheinlich schon selbst vor einem überlasteten Tunnel. Und solange am Surface-Port kein Rechner angeschlossen ist, der eine eingeschaltete DVS beinhaltet, sollte der iDR-Switch an dessen IP auch kein Dante in den Tunnel schicken. Es sei denn die M-Dante sendet Multicast. Das tut Die jedoch nur dann, wenn man tätig Streams bündelt, nicht automatisch global.

Also schließe das doch einfach mal so an wie es bei mir läuft, zusätzlich die Surface, und an den Surfaceport den Editor-RDP-Rechner. Ich denke weder, daß der iDR-Switch Dante überhaupt in den Tunnel schickt, noch daß Dante ACE lahmlegt.

Solange wie gesagt nirgends Multicast an alle Switchports erzwungen wird.

Ich möchte weiterhin bezweifeln das die IDR Switch wirklich dazu geeignet ist. A&H sagte bei der Frage "No" Wie stabil das läuft möchte ich nicht Live testen wenn plötzlich das Mixrack nicht reagiert ist das er unlustig. Dann lieber eine zweite Netzwerkkarte oder Cat5 Leitung ziehen.

Zitat von &quot;marcoboy&quot;

A&H sagte bei der Frage "No"

weder sagten, noch sagen Allen&Heath "no". Ganz im Gegenteil, Allen&Heath sagen präzise wie es geht.

Du hast echt ein übergeordnetes Problem, wenn Du das nicht hinbekommst. Statt das zuzugeben "bezweifelst" Du hier rum.

Zitat von &quot;marcoboy&quot;

Ich möchte weiterhin bezweifeln das die IDR Switch wirklich dazu geeignet ist.

Du bist voll peinlich ...wie immer

Zitat von &quot;bernd häusler&quot;

...
Ich hatte und habe kein Bedürfniss weitere 2-3 HE Shockmounted in Form eines 19" Rechners rumzuschleppen, ganz davon abgesehen Diesen aufzusetzen und zu backuppen...

mein remote-rechner hat etwa folgende gehäusemaße:
20x15x10cm
er ist mit einem Atom-prozessor ausgestattet (genügt mit der MADi-karte völlig) und hat eine schnelle festplatte, welche die möglichen 64kanäle ohne probleme mitschreiben kann.
ich habe mir den rechner von einem profi aufsetzen lassen. diese investition hat sich für mich bisher absolut gerechnet, das system läuft nun seit zwei jahren ohne ein einziges problem.
der Tonmike hier im forum hat sich übrigens genau den selben winz-rechner bauen lassen - und er ist ebenfalls sehr zufrieden

aber ich verstehe natürlich, das Dante für die zukunft interessanter sein könnte. schon in wenigen jahren sind die hardwareanforderungen für Dante bereits nur noch ein witz...deshalb ist MADI aber trotzdem noch nicht veraltet. :wink:

Woher hast du diese Aussage?

http://www.allen-heath.com/uk/Products/Pages/ProductDetails.aspx?CatId=GLDSeries&ProductId=Dante&SubCatId=AudioNetworkingOptionsGLD

Understanding M-DANTE.pdf öffnen und nach ganz unten scrollen.

Was zeigt das Bild ?

Was sagt dieser Satz aus?

"When the iLive network is bridged into the Dante network, it is not advised to
transmit Dante audio packets over the iLive network and Multicast Dante
streams should be avoided."

Warum zeigt das Bild immer eine management switch ? Warum stöpseln sie das auch nicht gleich wie du auf das IDR Rack?

Es sollte vermieden werden. Auch wenn du mulicast ausschaltest oder nur Unicast im Dante verwendest bleibt die Bedeutung des Satzes erhalten. Es hat schon seinen Grund warum das vermieden werden sollte, auch wenn es augenscheinlich funktioniert. Unicast zu verwenden führt dann zu Störungen wenn Teilnehmer im Netz nicht mehr erreichbar sind.

Ich frag mich jetzt was daran Peinlich ist deine Aussagen in zweifel zu ziehen? Dieser ganze Thread ist sowieso für jemanden der Probleme hat nicht mehr zu gebrauchen. Der Grund warum dieser erstellt wurde habe ich "dummdreist" gelöst :roll: Die Karte funktioniert hervorragend das ohne gebastel seltsamer Netzwehrstrukturen. Mir ist egal was du da zusammen stöpselst. Jemand baut das aber auf deinen Rat hin nach und steht dann plötzlich total doof da. Deshalb kann das ganze hier auch geschlossen werden. Das Thema hat sich erledigt. Ich danke vor allem TWOsider und anderen für ihre hilfreichen Beiträge.

Ich habe dieses Probleme nicht weil beim GLD die Karte im Pult steckt

Noch etwas abschließendes zum Thema. Der Primäre Port hat eine Besondere Funktion, er stellt beim Master den Clock. Wenn du dieses auf eine Switch steckst dessen Technischen Daten du nicht kennst ist auch ungewiss wie sie dieses Signal verzögert wird. Probleme mit knacken etc. wären nicht verwunderlich. Deshalb solltest du den Controller Port benutzen, da dieser das Dante Netzwerk nicht beeinflusst. So wie es dort gezeigt wird.

"Supports mix of 100 Mbps, 1Gbps, through 10Gbps networks" beantwortet alle Fragen welche Verbindungen Dante unterstützt.

Moin,

@ wora: ok, das 19"-Argument sticht bei Deinem Setup nicht. Da zeigt sich natürlich ein Vorteil von Hardware-Schnittstellen gegenüber virtuellen Ethernet-Soundkarten, der Rechner kann schlanker sein. Nicht daß ich jetzt umsteigen wollte, ich mag meinen all-in-one FOH-Platz sehr, aber vor guten Lösungen habe ich immer Respekt. Dante hin oder her, MADI will ich keinesfalls schlechtreden. Wie auch Du andeutest muß man eben die IT-Hausaufgaben machen (lassen). Dazu zählt auch der Umgang mit Ethernet, wenn man relevante Audio-Datenströme verlässlich übertragen will.

Mein all-in-one Rechner ist etwas größer, 25*28*12cm Multiplex(Holz)-Gehäuse mit 100% gefilterter Kühlung, braucht mit einer im Vergleich zum Atom fetten E7600 CPU im Mittel 40Watt (eine SSD). Die OS X Aktivitätsanzeige gibt 4,8MB/s empfangene, und 4,9MB/s gesendete Daten an. Das sind dann 9,7MB/s, also 78Mbit/s. Ob das jetzt brutto oder netto ist weiß ich nicht, nichtmal ob ich richtig rechne, so oder so ist das 100Mbit/s LAN damit gut ausgelastet, Dante und Editor funktionieren - über den iDR-Switch. Feste IPs, nirgends Multicast.

Gruß,

Bernd

ich vermute mal, daß Dante - weil Layer3 abhängiges Protokoll - nicht über den ACE-Tunnel läuft, weil ACE Layer2 ist. Abgesehen davon macht Dante im <10Mbit-Tunnel, vermutlich neben total priorisiertem ACE, keinen Sinn. Außerdem macht es sicher einen Unterschied, ob man die M-Dante als "Switch" benutzt, oder den iDR-Switch. Bei M-Dante steht nichts darüber ob die Ports über einen internen Switch verbunden sind, und schon garnichts darüber, wie dieser konfiguriert ist. Die iDR hat jedoch offensichtlich einen 4-Port-Switch (ein Port intern), vermutlich Layer3. Und weil der iDR-Switch in meinem kleinen Setup nicht intelligent sein muß klappt das, vermutlich gerade deswegen, weil er nicht intelligent, sondern einfach Layer3 ist.

marcoboy, ...ach vergiß es, was redest Du überhaupt mit, GLD hat eine ganz andere Struktur.

Dieser Beitrag wurde von marcoboy, einem von dir ignorierten Mitglied, erstellt. Diesen Beitrag anzeigen.

Sehr schade, daß man diese Anzeige nicht sperren kann

n'Abend

Zitat von &quot;marcoboy&quot;

Unicast zu verwenden führt dann zu Störungen wenn Teilnehmer im Netz nicht mehr erreichbar sind.

Das ist so nicht ganz korrekt. Unicast bedeutet zunächst erstmal nur, dass genau ein Empfänger angesprochen wird. Die Adressierung und damit die Unterscheidung zwischen Uni-/Broad-/Multicast läuft auf dem "Netzwerk"-Layer 3 (und aus verschiedenen Gründen teilweise auch noch auf Layer 2). Das Konzept einer "Verbindung" und eine Zusicherung von bestimmten Eigenschaften (z.B. Zuverlässigkeit der Übertragung, Einhaltung der Reihenfolge, usw.) ist jedoch auf Layer 4 - "Transport" - angesiedelt.

Ich kann z.B. UDP-Pakete per Unicast in die Welt schicken soviel ich will, ob die ankommen oder nicht stört meinen Sende-Prozess überhaupt nicht. Erst wenn beide Kommunikationspartner ein Protokoll sprechen, dass die gegenseitige Bestätigung von Paketen eingebaut hat (z.B. alles was über TCP abgewickelt wird) kommt es zu Problemen, wenn eine Seite der Verbindung plötzlich verschwindet. Da wird der TCP-Stack dann irgendwann sagen: "Hey, warte mal einen Augenblick bevor du weiter sendest, ich hab von der Gegenseite noch keine Bestätigung über den Empfang der letzten paar Pakete."

Bei einem Multicast-Protokoll erwartet man üblicherweise gar keine Bestätigung der einzelnen Empfänger, folglich kommt es hier also auch nicht zu Problemen, wenn einer der Empfänger aussteigt.

Richtigerweise müsstest du also oben einschränken: "Unicast mit TCP/IP"

Zitat von &quot;bernd häusler&quot;

[...] sollte der iDR-Switch an dessen IP auch kein Dante in den Tunnel schicken. Es sei denn die M-Dante sendet Multicast.

Nah dran. Zunächst: Ein Switch sendet an keine "IP" (Layer 3), er sendet an MAC-Adressen (Layer 2). Der IPv4-Stack eines jeden Geräts muss sich über ARP erstmal die MAC-Adresse der Ziel-IP besorgen, bevor er ein Paket auf die Reise schicken kann. Weiterhin: Wenn die Dante-Karte Broadcast senden würde, muss der iDR-Switch das in den Tunnel schicken. Sendet sie aber Multicast, hängt es von der Intelligenz des Switches ab. Das heißt: Selbst wenn keine DVS am anderen Ende hängt, kann es sein, dass der Dante-Verkehr in den Tunnel gespült wird, muss aber nicht.

Erklärung dazu: Switches arbeiten allgemein auf Layer 2 - "Data Link" - und treffen die Entscheidung, an welchem Port sie welche Pakete rausschicken (bei Ethernet) anhand der Empfänger (MAC)-Adresse in jedem Paket. Damit geht also erstmal nur Unicast, es sei denn man widmet "besondere" Adressen für Zwecke wie Broadcast oder Multicast um. Ein Switch wird z.B. ein Paket für den Empfänger FFFFFF-FFFFFF auf allen Ports ausgeben, denn diese Adresse ist die Broadcast-Adresse.
Bei Multicast gestaltet sich das etwas schwieriger, denn jetzt sind ja nicht mehr "alle" sondern nur noch "bestimmte" Empfänger mit den Paketen zu versorgen. Die eigentliche Multicast-Adressierung findet aber im Layer 3 statt, d.h. auf einer Ebene wo der Switch selbst erstmal nichts zu suchen hat. Wie bekommt man die Pakete nun trotzdem an alle Empfänger? Man macht einen Broadcast daraus. Der Sender schickt die Multicast-Pakete also auf Layer 2 (vereinfacht gesagt) an einen Pseudo-Empfänger mit der Adresse 01005E-xxxxxx raus und Switches sehen solche Adressen auch als Broadcast-Adressen an, werden die Pakete also auf allen Ports ausgeben. Das ist zwar jetzt etwas blöd, aber als Folge der Aufgabentrennung zwischen Layer 2 und 3 leider erstmal nicht zu umgehen.
Zur Rettung des Tages kommt nun IGMP Snooping daher. Multicast-Verkehr wird in Gruppen abgewickelt; ein Client, der Multicast einer bestimmten Gruppe empfangen will, meldet sich dazu per IGMP beim nächstbesten Router (und jetzt wirklich Router und nicht bloß Access-Point) an, dass er da bitte auch mit-empfangen möchte. Wenn der Switch jetzt hinreichend intelligent ist, diese IGMP-Nachrichten zu "erschnüffeln" (= zu snoopen), kann er entscheiden, ob die entsprechenden Multicast-Pakete auf einem Port ausgegeben werden müssen oder nicht. Das heißt: Nur wenn die Switches IGMP Snooping können, wird aus dem Layer 3 Multicast auch auf dem Layer 2 ein echter Multicast und die unnötige Übertragung von Metering und/oder Dante-Audio vermieden, sofern iLive und/oder Dante im Multicast-Modus betrieben werden.

Zitat von &quot;bernd häusler&quot;

[...] Das sind dann 9,7MB/s, also 78Mbit/s.

Die 100 MBit/s gehen in der Regel im Vollduplex, d.h. in jede Richtung jeweils 100 MBit/s, nicht zusammengenommen. Aber spielt auch keine Rolle, es funktioniert so und damit ist gut

Zitat von &quot;bernd häusler&quot;

weil der iDR-Switch [...] einfach Layer3 ist

Nur um das klarzustellen: Auf Layer 3 wird nichts geswitcht. Ein "Layer 3 Switch" heißt nur deswegen so, weil er gegenüber seinen "dummen", reinen Layer 2-Kollegen über zusätzliche Software verfügt, die ihm über seine eigentlich Kernkompetenz (nämlich das Switching) hinaus erlaubt, in höhere Protokoll-Ebenen zu schauen und darauf basierend "bessere" Entscheidungen zu treffen, um den Paket-Fluss zu optimieren, z.B. über das besagte Feature IGMP Snooping oder die automatische Erkennung und Priorisierung von VoIP. Geroutet wird auf Layer 3. Aber: Wahrscheinlich ausnahmslos alle hier im Feld-, Wald- und Wiesenbetrieb befindlichen iLive/Dante-Installationen bewegen sich in genau einem gemeinsamen IP-Netzwerk, es wird also nichts nirgendwohin geroutet.

Grüße
Joern

Zitat von &quot;TWOsider&quot;

...
Ich kann z.B. UDP-Pakete per Unicast in die Welt schicken soviel ich will, ob die ankommen oder nicht stört meinen Sende-Prozess überhaupt nicht. Erst wenn beide Kommunikationspartner ein Protokoll sprechen, dass die gegenseitige Bestätigung von Paketen eingebaut hat (z.B. alles was über TCP abgewickelt wird) kommt es zu Problemen, wenn eine Seite der Verbindung plötzlich verschwindet. Da wird der TCP-Stack dann irgendwann sagen: "Hey, warte mal einen Augenblick bevor du weiter sendest, ich hab von der Gegenseite noch keine Bestätigung über den Empfang der letzten paar Pakete."

Bei einem Multicast-Protokoll erwartet man üblicherweise gar keine Bestätigung der einzelnen Empfänger, folglich kommt es hier also auch nicht zu Problemen, wenn einer der Empfänger aussteigt...

ganz genau deshalb hat man irgendwann mal die möglichkeit geschaffen, multicast zu senden. vorher und ohne multicast war es manchmal so, das ein per WLAN angeschlossener laptop bei WLAN verbindungsproblemen die ganze pultbedienung lahmlegen konnte, weil der laptop eben keine antwort mehr zurückschichte. das pult hat dann einfach gewartet, bis er wieder was schickt... das ist mit zu anfang einmal passiert, das wünsche ich keinem. seit ich multicast verwende, gehört dieses horrorszenario allerdings der vergangenheit an.

Das meinte ich damit wora ohne näher darauf einzugehen. Danke für die Erklärung. Sollte man die Netzwerke nun trennen oder nicht?

Berd die Angriffe auf mich solltes du sein lassen. Bitte lese dir Regeln im Forum noch mal genau durch.

Zitat von &quot;marcoboy&quot;

...Berd die Angriffe auf mich solltes du sein lassen. Bitte lese dir Regeln im Forum noch mal genau durch.

nun, einer von euch beiden liegt eben falsch mit seinen aussagen zur netzwerkproblematik.
dazu möchte ich schreiben, dass mir Bernd insgesamt deutlich seltener mit fachlich falschen beiträgen auffällt...

da ich selbst keine GLD und keine Dantekarte besitze, kann ich eure beiträge leider nicht auf richtigkeit überprüfen.
nach dem durchlesen der beiträge in diesem thread bin ich der ansicht, das TWOsider hier eindeutig die meiste ahnung zu haben scheint. und auch er kritisiert deine ausführungen bzw. stimmt nicht mit deiner meinung überein.
es wäre schön, wenn man den konflikt in der diskussion irgendwie sinnvoll und für alle verständlich lösen könnte.

Ich lese bitte in diesem Thread nur noch Fragen von Leuten mit wenig oder keiner DANTE-Kompetenz und Antworten von Leuten mit echter DANTE Kompetenz. Besten Dank für die Beiträge von TWOsider. Gerne mehr davon.

Auch wenn mich die letzten Beiträge echt überfordern, die das Netzwerk anbelangen (ich kenne mich zwar mit den Basics aus aber das ist mir dann zuviel), nun ein update von mir:

Das mit Dante und iLive Netzwerk war nur ein Versuch - vielleicht auch aus Langeweile. Ich bin ein Mensch der gerne auf Try'n'Error versucht.

Nun wieder Dante Karte direkt 1:1 auf das Gigabit Interface des Rechners gesteckt, dann ist die ganze Switchgeschichte aus dem Thema raus.

Dabei gibts eben die beiden Fehler "512" und "1024" von der Virtual Soundcard (DVS). "512" kommt wenn beim Start der DVS kein Dante Master angeschlossen ist (oder noch nicht hochgefahren ist). "1024" kommt manchmal, auch wenn der Dante Master angesteckt ist. Netzwerkkabel 5 Sekunden raus, wieder anstecken und es funzt meistens. Nachher gibts keine Probleme mit dem Thema mehr, solange man zuerst alles ansteckt und DANN erst den PC einschaltet. Sonnst ab und anstecken bis es geht.

Ich hab auch schon mit den Menschen von Audinate darüber geredet, die meinen, dass es an dem Bonjour liegt und ich iTunes installieren solle, da hier eine neuere Version von Bonjour integriert sein soll als die, die es einzeln gibt. Mag sein, die Fehler treten nun nicht so oft auf.

Das mit dem geknackse ist nun auch weg, nachdem ich einen Quadcore mit 8 Gig Ram und SSD im Einsatz habe. Zusätzlich im Bios jede Hardware deaktiviert, die es nicht braucht und unter Windows alles ausgeschaltet, was zum Recorden keinen Sinn macht.
Habs auch testweise auf einem Macbook Pro probiert, da gibts weder mit der DVS noch mit knacksen Probleme.

Nach ein wenig recharchieren bin ich auf das Thema gestoßen, dass Windows eben kein echtzeitfähiges System ist, sondern alles in "Warteschlangen" abgearbeitet wird.

Momentan läuft alles, sodass ich damit leben kann. Werd mir aber sobald ich wieder mehr Zeit habe eure letzten Beiträge noch genauer geben. Und wegen der DANTE Kompetenz: Ich hab noch wenig, es wird aber mehr ;-).

Die Aussage von meinem vorreder erinnert mich irgendwie an meine Bewerbungsgespräche nach der Schule (ich habe keine Berufserfahrung - HAHA, woher soll ich denn die nehmen gleich nach der Schule?)