• Netzwerke und Pulte, die nicht von sich aus synchron sind, verunsichern anscheinend die User bei Spezialanwendungen. Nicht weiter verwunderlich. Wobei bei Pulten ja immer die Frage ist: Inserts oder nicht, Gruppen und was ist der maximal langsamste Weg von Input -> PA.


    Plug an Play und "Selbstkonfigurierende" Netzwerke wären in der Tat so ein Ding, dass ich mir für 2023 wünschen würde. Am liebsten gepaart mit AD Wandlern, die einen passiven Split (oder aktiven für alle die es kompliziert möchten) überflüssig machen.

  • Das ist so nicht korrekt. Die Pakete kriegen beim versenden einen TimeStamp. Bei AES67 & Dante wird der Link Offset beim Empfänger eingestellt (z.b. 1 ms). Der Sender sendet also die Pakete, macht den Timestamp drauf und er Empfänger spielt sie exakt 1ms später ab (durch PTP haben ja alle genau die gleiche Zeit auf NanoSekunden genau).


    Du hast leider den Ansatz nicht verstanden, diese Timestamps werden mit dem lokalen PTP Clock verglichen und und der Media Clock ggf. korrigiert. Im Grunde nimmt der Stream Empfänger den Clock des Senders an. Er synchronisiert sich auf den Stream und der Vorteil des CRF Formats ist nur das dort mehr Timestamps vereinbart wurden.


    Sehr perfekt sogar. Wie gesagt sogar Kabellängen werden ausgeglichen.

    Aber nur wenn man die Parameter der Geräte beeinflusst und unter Dante ist dies ja einfach da der Core aus einer Hand stammt. Mit AVB gibt es verschiedene Implementierungen und des Grundproblem kann auch Dante nicht ausblenden. "Bei AVB wird das beim Sender eingestellt und heisst Presentation Delay" dieser Parameter beschreibt die maximale Zeit inkl. Netzwerkdelay und wurde durch das command get/set max_transit_time ersetzt. Man kann das Path delay vom Cluster beeinflussen und somit einen Ausgleich unterschiedlicher Laufzeiten in den Geräten erreichen.



    Das ist auch nicht korrekt. Bei Dante kann ich die genauso Boundary Clocks (und auch noch Transparent Clocks) benutzen.


    Das dumme ist nur das es keine AVB Switch gibt welches mit den PTP Profil von Dante arbeiten würde und die es zuließe die Priorisierung per Hand vorzugeben. So kommt am Ende doch nur ein Transparent Clock zustande. Für die AV-Branche ausreichend aber in der Industrie wo AVB zum Einsatz kommt zu instabil.


    Im Grunde ging es im die Aussage das nur die synchronisierte PTP ausreichend wäre. Bei genauen hinschauen ist dies nicht der Fall, da der Media Clock sonst von der PTP wegläuft.

  • Zitat

    Du hast leider den Ansatz nicht verstanden, diese Timestamps werden mit dem lokalen PTP Clock verglichen und und der Media Clock ggf. korrigiert. Im Grunde nimmt der Stream Empfänger den Clock des Senders an. Er synchronisiert sich auf den Stream und der Vorteil des CRF Formats ist nur das dort mehr Timestamps vereinbart wurden.

    Ich hab wie gesagt von AES67, Dante und SMPTE2110 gesprochen. Da wird nichts verglichen. TimeStamp + LinkOffset = Sample/Frame wird abgespielt. Die Möglichkeit asynchrone Streams durchs Netzwerk zu bringen gibts offenbar im AVB standard. Ich hab noch kein Gerät in der Hand gehabt, welches das macht. Wenn du eines kennst, schau ich mir das sehr gerne einmal an.


    Zitat
    Aber nur wenn man die Parameter der Geräte beeinflusst und unter Dante ist dies ja einfach da der Core aus einer Hand stammt.


    Das Kabellängen ausgegelichen werden ist Teil des PTP Protokolls, da hat Dante wenig damit zu tun.

    Aber ja, ich würd für mein für PA links und PA rechts auch ohne Netzwerk nicht DA Wandler von 2 verschiedenen Herstellern mischen.


    Zitat

    Das dumme ist nur das es keine AVB Switch gibt welches mit den PTP Profil von Dante arbeiten würde und die es zuließe die Priorisierung per Hand vorzugeben. So kommt am Ende doch nur ein Transparent Clock zustande. Für die AV-Branche ausreichend aber in der Industrie wo AVB zum Einsatz kommt zu instabil.

    Es gibt ganz viele Switche die mit dem PTP Profil von Dante arbeiten und so als Boundary Clocks für Dante (und AES67 und SMPTE2110) nutzbar sind. Die gibts bei Arista, Cisco, Mellanox, Artel, Huawai und noch einigen anderen.


    Zitat

    Im Grunde ging es im die Aussage das nur die synchronisierte PTP ausreichend wäre. Bei genauen hinschauen ist dies nicht der Fall, da der Media Clock sonst von der PTP wegläuft.

    Die Synchronisierung durch PTP erlaubt es, Phasen und Sample genau über hunderte Kilometer Distanz abzuspielen. Der MediaClock kann per Definition in AES67/Dante/SMPTE2110 nicht von PTP weglaufen, da er direkt davon abgeleitet wird.

    Offenbar gibt es im AVB Standard Mechanismen, die es erlauben asynchrone Streams die nicht dem Hausclock folgen übers Netzwerk zu verteilen. Das ist sehr spannend und wenn es ein Produkt gibt welches dies in der Praxis Ermöglicht (und nicht nur eine theoretische Erwähnung im Standard) würde ich das sehr gerne kennen lernen und natürlich nachmessen. Ich bin da sehr offen um meinen Horizont zu erweitern.


    Edit: Zitat statt Code

    Einmal editiert, zuletzt von gemini ()

  • hast du eine Quelle für deine Ausführungen?

    Ich kann dir jetzt gerne den AES67-2018 Standard oder IEEE 1588-2008 (PTPv2) nennen, ich weiss aber nicht wieviel dich das effektiv weiterbringt. Für was hättest du gerne belege? Gerne suche ich dir das raus. Wenn deine Frage auf relation zwischen PTP und Media Clock abziehlt sagt der AES67-2018 Standard folgendes:


    Zitat

    Media clocks

    The media clock is used by senders to sample and by receivers to play digital media streams. The media clock has a fixed relationship to the network clock. The media clock and the network clock shall share the IEEE 1588 epoch of 1 January 1970 00:00:00 TAI, as defined in IEEE 1588-2008 clause 7.2.2. Digital audio to be carried on the network shall be sampled according to the media clock, or sampling-frequency converted to conform to the media clock.

    The media clock shall advance at an exact rate with respect to the network clock. The rate of the media clock shall be the same as the audio sampling frequency.

    This standard supports three sampling frequencies: 44,1 kHz, 48 kHz and 96 kHz (see 7.1). The media clock for an audio stream sampled at 48 kHz advances exactly 48 000 samples for each elapsed second on the network clock.