Erfahrungen mit Audio-over-IP

tovow
Aktiver Hörer
Beiträge: 220
Registriert: 16.06.2012, 22:32
Wohnort: Rheingau

Beitrag von tovow »

Hallo Fujak,

sehr schön beschrieben und erklärt vor allem auf Deutsch.
Gerade Gefunden.
Wie Hier:"Die wunderbare Welt des IP-Clockings" Kann sein das, dass schon mal Verlinkt war.
https://focusrite.de/news/the-wonders-of-ip-clocking
und Hier noch was zu Digital I/O & Clocking
https://medium.com/focusrite-spectrum/s ... 24a1c216b7
und was mich Überrascht hat die Antwort auf die Frage: Can An External Clock Improve Sound Quality?
Es gibt noch einen weiterführenden Link, der schon etwas älter ist.
Group Test: 7 Master Clocks: https://www.soundonsound.com/techniques ... ster-clock

Beste Grüße
Theo
Bild
taggart
Aktiver Hörer
Beiträge: 475
Registriert: 28.04.2011, 17:23
Wohnort: Köln

Beitrag von taggart »

Hallo Fujak,
Fujak hat geschrieben:Der DAC bekommt neben dem Audio-Stream lediglich die Information, mit welcher Samplerate er das Digitalsignal wandeln soll, und alle 250ms eine Zeitmarke, die ihn wieder auf eine exakte Zeitbasis zu den anderen Geräten bringt. Sein interner Oszillator bleibt also viel weitgehender unbeeinflusst von externen Einflüssen, als beispielsweise bei der Anlieferung eines SPDIF-Signals mit seinem integrierten Taktsignal, auf das sich der DAC synchronisieren muss.
Bist du denn sicher, dass das so stimmt?

Die 250ms-Zeitmarke ist doch lediglich Teil des Dante-Protokolls. Und dein DAC ist - für mein Verständnis - im Dante-Netzwerk als eigenes Gerät gar nicht sichtbar. Die Dante-Beteiligten sind doch nur die Virtual-Soundcard und das Digimedia-Board.

Der DAC bekommt also m.M.n. seinen Takt weiterhin als I2S-Slave von der Clock des Digimedia-Boards.
Denn das I2S-Protokoll kennt doch die 250ms-Zeitmarke gar nicht.

Gruß, Christoph
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Christoph,

ich sehe das so wie du. Das Synchronisierungssignal innerhalb des DANTE Netzwerks hat direkt nichts mit dem Taktsignal für den DAC zu tun, sondern damit, dass mehrere Senken synchronisiert werden können, um ein Signal zeitgleich abzuspielen. Das wird benötigt, wenn man z.B. per DANTE ein PA-System mit mehren Senken aufbaut. Ich finden folgenden Link zu einem Dokument von dbaudio dazu sehr aufschlussreich: DANTE Audio Networking.

Aber: All das wird nur relevant, wenn es mehrere DANTE-Senken gibt. In den meisten hier im Forum diskutierten Setups gibt es doch nur eine einzige Senke, oder? So wie ich das verstehe spielt in diesem Fall dieses Synchronisierungssignal keine Rolle. Die (einzige) Senke wird in diesem Fall die DANTE-interne Clock vorgeben, sie fordert Datenpakete vom Sender ein und gibt diese mit dem eigenen erzeugten Audiotakt aus.

Spannend wird es, wenn es mehrere Senken gibt, die synchronisiert werden sollen. Was macht dann ein DANTE-Device, dessen Takt dem Systemtakt hinterherhinkt? Werden dann Samples verworfen, oder wird die lokale Clock dieser Senke dann nachgeregelt, oder wird per SRC (quasi eine Neuabtastung) angepasst? Ich gehe davon aus, dass ein Verwerfen von Samples nicht erfolgt, sondern entweder der Takt (wie bei einer PLL) nachgeführt wird, oder dass neu abgetastet wird. Und dann sind wir wieder beim hier so verpönten Einfluss einer mit dem Datensignal mitgeführten Clock auf die Clock eines Wiedergabedevices.

There´s no such thing as a free lunch.

Grüße,
Andree
Bild
Salvador
Aktiver Hörer
Beiträge: 2061
Registriert: 01.12.2012, 10:58
Wohnort: Region Hannover

Beitrag von Salvador »

Hallo Christoph,

Sehe ich genauso, deswegen lohnt sich beim Dantebord theoretisch auch eine sehr gute Clock.
Dante sorgt für einen gleichmäßigen Fluss der Information bis ins Dantedevice. So hat man dann kontinuirlichen und kaum fluktuierenden Datenfluss mit hochpräziser Taktung bis in den DAC hinein. Das ist fein!

Grüße,
Andi
taggart hat geschrieben:Hallo Fujak,
Fujak hat geschrieben:Der DAC bekommt neben dem Audio-Stream lediglich die Information, mit welcher Samplerate er das Digitalsignal wandeln soll, und alle 250ms eine Zeitmarke, die ihn wieder auf eine exakte Zeitbasis zu den anderen Geräten bringt. Sein interner Oszillator bleibt also viel weitgehender unbeeinflusst von externen Einflüssen, als beispielsweise bei der Anlieferung eines SPDIF-Signals mit seinem integrierten Taktsignal, auf das sich der DAC synchronisieren muss.
Bist du denn sicher, dass das so stimmt?

Die 250ms-Zeitmarke ist doch lediglich Teil des Dante-Protokolls. Und dein DAC ist - für mein Verständnis - im Dante-Netzwerk als eigenes Gerät gar nicht sichtbar. Die Dante-Beteiligten sind doch nur die Virtual-Soundcard und das Digimedia-Board.

Der DAC bekommt also m.M.n. seinen Takt weiterhin als I2S-Slave von der Clock des Digimedia-Boards.
Denn das I2S-Protokoll kennt doch die 250ms-Zeitmarke gar nicht.

Gruß, Christoph
Bild
h0e
Administrator
Beiträge: 3864
Registriert: 11.11.2013, 09:40
Wohnort: München

Beitrag von h0e »

Hallo zusammen,

es scheint doch zwei Effekte zu geben.
Es wurde berichtet, dass auch von Dante über Spdif ausgegeben sich bereits eine Klangverbesserrung insbesondere in Bezug auf Musikfluss einstellt. Das widerspricht dervon Fujak aufgestellten Theorie.
Wohl übereinstimmend wird auch berichtet, dass das Umgehen von SPDIF /AES-EBU zugunsten von I2S nochmals einen Schritt nach vorne bringt.
M.E. nach ist die isolierte Clocking Hypothese ungeeignet, um diese Effekte zu erklären.
Ist im Grunde ja egal, es reicht, wenn es tut, aber wir sind halt neugierig und wollen das auch verstehen. :wink:

Grüsse Jürgen
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3997
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo,

es geht vielleicht um die Arbeitsweise des Buffers im Dantechip, aus dem die ankommenden Daten für die Musiktaktung ausgelesen oder abgegeben werden.

Wie funktioniert die Befüllung, ist das mit einem Rückkanal zum Sender gekoppelt wie bei asynchronem USB Audio oder vielleicht hier gar nicht mehr nötig?

Ist Buffergröße und -geschwindigkeit anders als beim normalen Neztwerk?

Gruß

Bernd Peter
Bild
chriss0212

Beitrag von chriss0212 »

Also... mit den Erfahrungen die ich in Sachen synchrones ausspielen von Video auf beliebig viele Endgeräte sammeln durfte... würde ich das so machen:

Es ist ja Fakt: es gibt einen Master, der eine Clock für sämtliche Dante Devices vorgibt... damit weiß schon mal jeder "wie späht es ist".

Dann gibt es eine Delay Einstellung womit die Dante Devices wissen zu welchem Zeitpunkt sie die Information ausspielen müssen...

Außerdem hat das sendende Dante Device auch all diese Infos und weiß somit wann es wieder neue Informationen ins Netz schicken muss, damit alle Endgeräte genügend Daten im Buffer haben...

Somit ist eine bidirektionale Verbindung nicht nötig... und auch nicht möglich!

Warum nicht möglich: man kann von einem Sender an beliebig viele Endgeräte gleichzeitig "streamen". Das wäre mit eine bidirektionalen Kommunikation aus meiner Sicht nicht möglich.

Aber nur meine Theorie... und wie ich es bauen würde...

Viele Grüße

Christian
chriss0212

Beitrag von chriss0212 »

Ach... und wenn das seitens Audionate so gemacht wurde erklärt das, warum man bei verwirrenden Netzwerk Konfigurationen Musik spielen aber das Dante Device nicht konfigurieren kann...

Wenn die Daten per Multicast versendet werden, kann das ja jeder empfangen... auch, wenn das Endgerät nicht bekannt ist!

Grüße

Christian
tovow
Aktiver Hörer
Beiträge: 220
Registriert: 16.06.2012, 22:32
Wohnort: Rheingau

Beitrag von tovow »

Hallo,

ich denke Fujak hat schon Recht. Weil mbMn. der DAC im Netzwerk nicht sichbar ist, aber
der Ultimo Chip kennt bzw. Versteht den DAC und Umgekehrt.
Das steht in den Specs dazu:
When a Dante-enabled network device is operating in PTP clock master mode, its locally-sourced clock is
used to provide network time. All other Dante devices are then synchronized to this clock.
"Conceptually, every word clock edge has a network time in seconds/nanoseconds associated with it.
Word clock edges on different modules in the network are time aligned with sample accuracy throughout the network".

When operating in slave mode, the module will tune the VCXO based on measured offsets from the
network time signal as broadcast by the clock master.
"The VCXO is used to derive low jitter local clocks,
namely, I2Sx_MLCK, I2Sx_SCLK and I2Sx_LRCLK that have been synchronized to network time".
Also kennt der Ultimo Chip den DAC. Und zwar Bidirektional.

Bild


Beste Grüße
Theo
Bild
chriss0212

Beitrag von chriss0212 »

Hallo Theo,

Das Dante Device kennt den DAC nicht... muss es auch nicht. Der DAC läuft ja als Slave und zieht sich die Clock aus dem I2S Signal.
In meinem DAC, der ebenfalls über I2S angesteuert wird ist überhaupt kein Clock Baustein mehr vorhanden.

Das Bild was Du gepostet hat, zeigt nur, dass der Baustein auch einen I2S Eingang hat der von einem AD- Wandler bespielt werden könnte oder, wie bei Micromedia, vom SPDIF Eingang

Leider ist die beim Micomedia nicht vorgesehen ihn extern mit I2S zu bespielen, da dafür auch noch eine Signalumschaltung hätte verbaut werden müssen ;(

Viele Grüße

Christian
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo zusammen,

ich hatte leider heute wenig Zeit, mich inhaltlich mit dem weiteren Fortgang der interessanten Diskussion zu befassen, daher erst jetzt meine Reaktion. Zunächst revidieren muss ich meine Äußerung, wonach der DAC das Zeitsignal aus dem Dante-Netzwerk empfängt. Das tut er natürlich nicht, sondern lediglich das vorgeschaltete Danteboard; da bei mir das Board im DAC integriert ist, habe ich das gedanklich versehentlich in einen Topf geworfen.

Was die weiteren Aspekte des Clockings anbelangt, so ist die Sache nicht mit der Audio-Übertragung via PCM zu vergleichen, auch nicht die Übertragung von PCM-Daten über Ethernet oder WLAN, wie wir es vom herkömmlichen Streaming kennen. Auf der Ebene der Netzwerk-Layer findet die PCM-Übertagung im Ethernet auf der sog. Layer2-Ebene statt, die einfacher gehalten ist und auch keine IP-basierte Adressierbarkeit sondern nur Punkt-zu-Punkt-Übertragung erlaubt.

Die Audio-Übertragung bei Dante findet hingegen auf auf einem darüber liegenden Layer 3 (IP-Protokoll) statt, bei dem die Audio-Informationen statt über einen PCM-Stream über IP-basierte (und damit auch genau adressierbare) Datenpakete versandt wird. Diese Datenpakete beinhalten keine Taktinformation in Form eines Clocking-Signals sondern nur noch die Information über die Samplerate, mit der die Folgegeräte das Signal zu verarbeiten haben. Das hier von vielen eingesetzte Digimediaboard kann diese Information zwar auslesen (und meckert auch, wenn Audio-PC eine andere Samplerate eingestellt hat als das Digimedia-Board), aber es kann diese Information nicht nutzen für eine automatische Sampleraten-Umschaltung, sodass man sich für eine feste Samplerate entscheiden muss.

Das Digimedia-Board hat nun auf seiner Empfangsseite (es besitzt ja auch noch eine für uns nicht genutzte Senderseite) die Aufgabe, die IP-basierten Datenpakte, in denen das Audiosignal versendet wird, wieder in ein I²S-Signal (bzw. SPDIF-Signal) zu übersetzen, also aus Datenpaketen wieder einen Stream zu basteln. Dabei wird der für den DAC erforderliche Takt aus der 27MHz-Referenzclock abgeleitet und zusammen mit dem Audiosignal via I²S oder SPDIF an den DAC weitergeleitet.

Und hier liegt der Knackpunkt meiner vorangegangenen Äußerung, den ich zu verkürzt und damit offenbar missverständlich ausgedrückt hatte: Der DAC synchronisiert sich zwar auf das vom Danteboard generierte Clock-Signal, welches natürlich Master für den DAC ist. Der DAC synchronisiert sich aber nicht auf die Clock-Information des senderseitigen PCM-Streams. Das ist das, was ich mit meiner Äußerung meinte, wonach der DAC unbeeinflusst vom Clocksignal bleibt - nämlich dem Clocksignal am senderseitigen Gerät (Audio-PC o.a.).

Es ist also quasi ein Reclocking des Taktsignals, indem das Audiosignal beim Verpacken in IP-basierte Datenpakete kein Clockingsignal mehr enthält und am Ende ein vom Dante-Empfängerboard neu generierter Takt zum Audiosignal gefügt wird, den der DAC zum Synchronisieren verwendet (sei es über I²S oder über SPDIF).

Das ist jetzt vereinfacht dargestellt. Es gibt da noch ein paar Dinge, die auch mir nicht so klar sind, denn so gesehen dürfte die Qualität des Zuspielers keinen Einfluss auf die Klangqualität haben, tut er aber (wie wir es auch beim SPDIF-Reclocking kennen) - z.B. was das verwendete OS oder die Playersoftware anbelangt. Es muss also u.a. der Jitter im Zuspieler-PC Einfluss auf die Art und Weise haben, wie der PCM-Stream in IP-basierte Datenpakete zerlegt und versandt wird. Da endet auch mein bisheriges Wissen. Vielleicht weiß hier jemand von Euch mehr.

Grüße
Fujak
Bild
h0e
Administrator
Beiträge: 3864
Registriert: 11.11.2013, 09:40
Wohnort: München

Beitrag von h0e »

Hallo Fujak,

was ist " PCM-Daten über Ethernet"?
Wenn ich mal meinen Linn als Beispiel nehme, der holt sich über Ethernet die PCM Daten vom NAS.
Es steuert also wie bei Dante das Gerät den Datenfluss, dass auch den DAC füttert.
Und auch das geschieht auf Layer 4 und darüber.

Layer 1= Networklayer -> sprich Hardware
Layer 2 = Sicherungsschicht (Data Link Layer) ->Ethernet
Layer 3 = Vermittlungsschicht (Network Layer) -> IP
Layer 4 = Transportlayer -> TCP, UDP etc.

Da die Daten per http Request vom Renderer von der Quelle geholt werden, handelt es sich wohl auch um eine TCP/IP Verbindung, auch wenn ich dazu nichts substantielles gefunden habe.
Auch setzt der Renderer ein taktfreies Datenpaket entsprechend seiner eigenen Clock in Audiosignale um.

Den einzig substatiellen Unterschied, den ich entdecken kann ist, dass bei AoIP ein Protokoll verwendet wird, dass eben genau für die Übertragung von Audiodaten und -takt gedacht ist.
Das könnte m.E. ein Vorteil sein.

Bei USB ist es etwas komplizierter. Aber aber asynchroner Übertragung steuert doch auch dort das den Datenstrom an den DAC ausgebenede Device die Übertragung.

USB und DLNA/UPNP Geräte verwenden in der Regel große Cache Speicher, um Störungen im Datenfluss zu kompensieren. Das scheint bei Dante anders zu sein, die einstellbaren Latenzen sind scheinbar sehr klein.
Da Dante für Live Anwendung gedacht ist, ist das auch egal, denn vorbei ist vorbei, das braucht man nicht wiederholen. Also das Netzwerk stabil halten und den Cache klein halten.
Das könnte tatsächlich mal ein Ansatz sein? :roll: :?

Grüsse Jürgen
Bild
Hans-Martin
Aktiver Hörer
Beiträge: 9118
Registriert: 14.06.2009, 15:45

Beitrag von Hans-Martin »

h0e hat geschrieben: USB und DLNA/UPNP Geräte verwenden in der Regel große Cache Speicher, um Störungen im Datenfluss zu kompensieren. Das scheint bei Dante anders zu sein, die einstellbaren Latenzen sind scheinbar sehr klein.
Da Dante für Live Anwendung gedacht ist, ist das auch egal, denn vorbei ist vorbei, das braucht man nicht wiederholen. Also das Netzwerk stabil halten und den Cache klein halten.
Das könnte tatsächlich mal ein Ansatz sein? :roll: :?
Hallo Jürgen,
ich denke, du bist auf der richtigen Spur.
Gert hat hier einst sein Konzept vorgestellt, die Zeitkonstante der PLL in einen feineren Bereich umzuschalten, nachdem die PLL grob gefangen hat, um eine exaktere Synchronisation zu ermöglichen. Da ging es wohl um einen SPDIF-Eingangsbaustein.

Fujaks kaskadierte Mutec MC-3+ zeigten eine qualitative Steigerung gegenüber dem einzelnen Gerät.

Die Vorstellung, Daten in einen FiFo-Puffer zu laden und dann sauber zu takten, ist ein schönes Ideal, aber in der Praxis scheint es unbeachtete Einflussgrößen zu geben, wozu ich die PLL zähle, die Überlaufen und zu wenig Pufferfüllung vermeiden soll. Da ist ein großer Puffer mit großen Zeitzyklen gleichzusetzen, ein kleiner Puffer mit kleinen. Der Fangbereich der PLL ist in meiner Vorstellung zugleich auch ein Indikator für die resultierenden Timingfehler, große Puffer sind auch mit größeren Fehlern der langsamen PLL verbunden. Für das Neutakten wird auch eine PLL benötigt. Irgendwo habe ich mal gelesen, dass eine digitale PLL vorliegenden Jitter auf 1/100 reduzieren kann (eine analoge PLL nur auf 1/30), endliche Werte. Ein Rest bleibt noch zu verbessern.
Grüsse Hans-Martin
Bild
chriss0212

Beitrag von chriss0212 »

Hallo Jürgen
Da die Daten per http Request vom Renderer von der Quelle geholt werden, handelt es sich wohl auch um eine TCP/IP Verbindung, auch wenn ich dazu nichts substantielles gefunden habe.
Auch setzt der Renderer ein taktfreies Datenpaket entsprechend seiner eigenen Clock in Audiosignale um.
Hallo Jürgen,
Das ist so nicht unbedingt richtig. Da die Daten per Multicast versendet werden können muss es sich zumindest dann um eine einseitige "Verbindung" handeln.
Wenn Unicast gesendet wird, werden die Daten zwar angefordert, dies kann aber ohne weitere Synchronisation erfolgen, da es ja reicht, wenn der Sender weiß wer die Daten haben möchte. Die Zieladresse ist dann nur wichtig, damit der Switch weiß, an wen er die Daten weiterleiten muss.

Und da es eine Clock des Masters, Delay und Buffer im Setup bekannt sind, ist eine weitere Synchronisation aus meiner Sicht auch nicht nötig.

Siehe auch:
https://de.m.wikipedia.org/wiki/Dante_( ... protokoll)

Viele Grüße

Christian
chriss0212

Beitrag von chriss0212 »

Hallo Ulli

Dann ist das, was ich mit meinem Hausfrauenlatein zusammengereimt und versucht habe zu erklären, ja gar nicht mal verkehrt... nur nicht komplett :cheers:

Staubwedelnde Grüße

Christian
Antworten