Bernd Peter (Dynaudio Focus 60 XD)
Forumsregeln
Bei Vorstellungen steht die persönliche, subjektive Erfahrungswelt des Verfassers im Vordergrund. Insbesondere soll die Vorstellung als "Visitenkarte" des Mitglieds gewürdigt bzw. respektiert werden. Dialoge sollten hier vorrangig mit dem Verfasser und nicht mit Dritten geführt werden. Siehe auch die Forumsregeln.
Bei Vorstellungen steht die persönliche, subjektive Erfahrungswelt des Verfassers im Vordergrund. Insbesondere soll die Vorstellung als "Visitenkarte" des Mitglieds gewürdigt bzw. respektiert werden. Dialoge sollten hier vorrangig mit dem Verfasser und nicht mit Dritten geführt werden. Siehe auch die Forumsregeln.
-
- Aktiver Hörer
- Beiträge: 4008
- Registriert: 04.05.2010, 19:37
Hallo,
mal ganz anders gedacht und deshalb in die Runde gefragt:
das mit dem SRC kann ich mir beim S/PDIF Eingang ja gut vorstellen, da kommt ja ein Musiksignal, aber:
wenn die Daten vom Netzwerkeingang kommen und erst im FPGA von audinate daraus ein Musiksignal gemacht wird?
Braucht es dann am S/PDIF Ausgang den SRC, wenn ich die 24/48 beibehalte?
Gruß
Bernd Peter
mal ganz anders gedacht und deshalb in die Runde gefragt:
das mit dem SRC kann ich mir beim S/PDIF Eingang ja gut vorstellen, da kommt ja ein Musiksignal, aber:
wenn die Daten vom Netzwerkeingang kommen und erst im FPGA von audinate daraus ein Musiksignal gemacht wird?
Braucht es dann am S/PDIF Ausgang den SRC, wenn ich die 24/48 beibehalte?
Gruß
Bernd Peter
Hallo Bernd Peter,
Interessant für die Clock- und Jitter-Spezialisten wird sein, mit welcher Güte das PCM-Signal aus dem IP-zu-PCM Umsetzer herauskommt (dedizierte Clocks für 44k1/48k Familie?, selbst erzeugte Clock im FPGA?). Der ASRC kann an dieser Stelle erzeugten Jitter nicht wirklich ausmerzen, selbst wenn am Ausgang des ASCR eine hochgenaue Clock den Takt vorgibt. Ein ASRC führt eine Art "Neuabtastung" des anliegenden Signals mit dem am Ausgang anliegenden Takt durch.
Grüße,
Andree
Brauchen? Nein. Aber wie die Beschaltung wirklich funktioniert lässt sich aufgrund der wenigen Information nicht belastbar sagen. Ich gehe davon aus, dass ein auf der Platine befindlicher Prozessor (evtl. der AUDINATE FPGA) aus dem blockweisen IP-Paketen ein PCM-Signal erzeugt, das dann in SPIF/AES/I2S vorliegt. Damit geht es in den SRC. Aus Sicht der SRC mit seiner Routingfunktion (mehrere Input, mehrere Outputs) ist diese Signalquelle nur eine von mehreren, die er sieht und in das Wunschformat wandelt. Wie gesagt, ich zweifle daran, dass der bypass implementiert ist.Bernd Peter hat geschrieben:Braucht es dann am S/PDIF Ausgang den SRC, wenn ich die 24/48 beibehalte?
Interessant für die Clock- und Jitter-Spezialisten wird sein, mit welcher Güte das PCM-Signal aus dem IP-zu-PCM Umsetzer herauskommt (dedizierte Clocks für 44k1/48k Familie?, selbst erzeugte Clock im FPGA?). Der ASRC kann an dieser Stelle erzeugten Jitter nicht wirklich ausmerzen, selbst wenn am Ausgang des ASCR eine hochgenaue Clock den Takt vorgibt. Ein ASRC führt eine Art "Neuabtastung" des anliegenden Signals mit dem am Ausgang anliegenden Takt durch.
Grüße,
Andree
-
- Aktiver Hörer
- Beiträge: 4008
- Registriert: 04.05.2010, 19:37
Hallo Andree,
die ankommenden Datenpakete bei der LAN Buchse werden sicherlich als erstes nach Bittiefe und Samplerate untersucht.
Eigentlich sollte es softwareseitig nicht das Problem sein, bei richtiger Kombination von 24/48 den Weg zum SRC zu sperren und sofort mit der Musiktaktung zu beginnen.
Aber wir wissen es nicht, wie programmiert wurde.
Gruß
Bernd Peter
die ankommenden Datenpakete bei der LAN Buchse werden sicherlich als erstes nach Bittiefe und Samplerate untersucht.
Eigentlich sollte es softwareseitig nicht das Problem sein, bei richtiger Kombination von 24/48 den Weg zum SRC zu sperren und sofort mit der Musiktaktung zu beginnen.
Aber wir wissen es nicht, wie programmiert wurde.
Gruß
Bernd Peter
Hallo Bernd Peter,
Und ich frage mich immer noch woher die Clock kommt und wie gut sie ist.
Grüße,
Andree
Ja. Und nicht nur das. Wir wissen (auf Basis auf der Fotos) auch nicht wie die Prozessoren miteinander verschaltet sind. Eventuell lässt sich das System gar nicht so programmieren. Du kannst ja versuchshalber den Hersteller kontaktieren und nachfragen.Bernd Peter hat geschrieben:Aber wir wissen es nicht, wie programmiert wurde.
Und ich frage mich immer noch woher die Clock kommt und wie gut sie ist.
Grüße,
Andree
Hallo Bernd Peter,
ich habe mich mal anhand des Platinenbildes mit dem befasst, was da in der Nähe der Clock passiert. Bei dem direkt neben dem Oszillator ansässigen Bauteil (Si5351) handelt sich um einen programmierbaren I²S Clock-Generator, der seine Referenztaktung von dem kleinen Oszillator links darunter ableitet. Der dürfte 26 oder 27MHz haben.
Der Clock-Generator kann dabei lt. Specs mehrere Frequenzen (bis acht) vom Referenztakt ableiten. An zwei dieser Clockausgänge werden die beiden Basisfrequenzen generiert, wie man sie bei den üblicherweise verwendeten Oszillatoren vorfindet, nämlich 24.576 MHz und 22.5792 MHz. Außerdem wird an weiteren Clockausgängen der Takt für den Ethernetcontroller (125 MHz). Ein kleines leistungsfähiges Bauteil, das zu guter letzt auch einen I²S-Schnittstelle breitstellt, die - wenn ich die Leiterbahnen richtig erkenne - auch nach außen an einen Anschlussport geführt wird (auf der Platine mit F709 bezeichnet).
Die Frage, die ich mir stelle ist, ob man bei einem Abgriff des I²S den SRC43921 umgeht.
Ich muss aber gestehen, dass das nicht als gesichertes Wissen um die internen Abläufe des Booards handelt, sondern um einen reinen Indizien-Prozess.
Grüße
Fujak
ich habe mich mal anhand des Platinenbildes mit dem befasst, was da in der Nähe der Clock passiert. Bei dem direkt neben dem Oszillator ansässigen Bauteil (Si5351) handelt sich um einen programmierbaren I²S Clock-Generator, der seine Referenztaktung von dem kleinen Oszillator links darunter ableitet. Der dürfte 26 oder 27MHz haben.
Der Clock-Generator kann dabei lt. Specs mehrere Frequenzen (bis acht) vom Referenztakt ableiten. An zwei dieser Clockausgänge werden die beiden Basisfrequenzen generiert, wie man sie bei den üblicherweise verwendeten Oszillatoren vorfindet, nämlich 24.576 MHz und 22.5792 MHz. Außerdem wird an weiteren Clockausgängen der Takt für den Ethernetcontroller (125 MHz). Ein kleines leistungsfähiges Bauteil, das zu guter letzt auch einen I²S-Schnittstelle breitstellt, die - wenn ich die Leiterbahnen richtig erkenne - auch nach außen an einen Anschlussport geführt wird (auf der Platine mit F709 bezeichnet).
Die Frage, die ich mir stelle ist, ob man bei einem Abgriff des I²S den SRC43921 umgeht.
Ich muss aber gestehen, dass das nicht als gesichertes Wissen um die internen Abläufe des Booards handelt, sondern um einen reinen Indizien-Prozess.
Grüße
Fujak
Hallo zusammen,
aus den sichtbaren Bauteilen würde ich darauf tippen, dass der Freescale Prozessor die Audiosamples per I2S mit der gewünschten Rate an den SRC gibt. Wenn ich das Datenblatt des SRC richtig lese, kann I2S nicht über den bypass geschaltet werden. Das Signal geht also immer durch den ASRC-Prozess.
Grüße,
Andree
aus den sichtbaren Bauteilen würde ich darauf tippen, dass der Freescale Prozessor die Audiosamples per I2S mit der gewünschten Rate an den SRC gibt. Wenn ich das Datenblatt des SRC richtig lese, kann I2S nicht über den bypass geschaltet werden. Das Signal geht also immer durch den ASRC-Prozess.
Wenn der Si5351 das Clocksignal erzeugt, kann ich mir nicht vorstellen, dass dies gerade bei Verwendung eines ASRC den Anforderungen von Jitter-Hörenden genügt.Fujak hat geschrieben:An zwei dieser Clockausgänge werden die beiden Basisfrequenzen generiert, wie man sie bei den üblicherweise verwendeten Oszillatoren vorfindet, nämlich 24.576 MHz und 22.5792 MHz.
Grüße,
Andree
-
- Aktiver Hörer
- Beiträge: 4008
- Registriert: 04.05.2010, 19:37
Hallo Bernd Peter,
Grüße,
Andree
(*) Unter der Annahme, dass der Si5351 die Clocks erzeugt.
Da liegst du leider falsch. Dein Gerät empfängt zwar die Daten paketorientiert per LAN, erzeugt daraus aber intern ein getaktetes PCM-Signal auf der Eingangsseite des ASRC (z.B. mit 44,1 kHz wie zuvor von dir berichtet). Daraus macht der ASCR dann die von berichteten 48 kHz auf der Ausgangsseite. Dein Gerät hängt zwar nicht von der Clock des Senders ab und nutzt eine eigene interne Clock. Diese bestimmt aber damit (wie bei USB-Audio) allein die Taktgenauigkeit -- oder Ungenauigkeit.Bernd Peter hat geschrieben:ein ASRC arbeitet asynchron, das ist beim S/PDIF Eingang gegeben, nicht bei LAN.
Dann ist der 50-150 ps Jitter des Si5351 (*) wohl doch gar nicht so schlimm.Bernd Peter hat geschrieben:Noch nie habe ich mit einem Notebook ein derart schönes Klangbild wahrnehmen dürfen.
Grüße,
Andree
(*) Unter der Annahme, dass der Si5351 die Clocks erzeugt.
Hallo,
finde ich interessant. Bernd Peter sagt, es klingt sehr gut, so gut wie noch nie vom Notebook. Nach jetzigem Wissensstand wird vermutet, dass die Clock Jitter im Bereich von 50 - 150 ps verursacht. Wenn ich es recht mitbekommen habe, gibt es auch Femtoclocks, dass hieße um schlappe drei Größenordnungen niedrigerer Jitter. Ich maße mir bei diesem Thema nicht die geringste Sachkompetenz an, aber wenn man das mal zu Ende denkt, bleibt dann nicht einfach eine mögliche Erklärung:
Unterschied zwischen Dante und nicht Dante ist eine Masterclock für den Datenverkehr
und
diese Materclock hat Jitter der deutlich höher ist als die Singxers und wer weiß nicht was da da noch kreucht und fleucht auf dieser Welt.
Kann es sein, dass es besser ist nur eine Masterclock zu haben als mehrere Clocks, selbst wenn die Clocks einen besseren Jitter haben als die eine Masterclock, sprich ist das delta (im Takt bzw. Jitter) zwischen mehreren selbst hochpräzisen Clocks schädlicher als der höhere Jitter einer nicht ganz so präzisen Masterclock? Das wäre ja ein Ding!
Wobei wie ich die Jitter-Ritter kenne, kommt ihr gleich auf die Idee, dass eine noch bessere Masterclock nochbeser klingt als eine recht einfache. Gut genug gibt es bei Euch ja nicht
Vielleichthaabe ich auch nur viel Unsinn erzählt, wäre nicht das erste und ist sicherlich auch nicht das letzte Mal.*
Gruß
Uwe
* Es irrt der Mensch, solange er strebt
finde ich interessant. Bernd Peter sagt, es klingt sehr gut, so gut wie noch nie vom Notebook. Nach jetzigem Wissensstand wird vermutet, dass die Clock Jitter im Bereich von 50 - 150 ps verursacht. Wenn ich es recht mitbekommen habe, gibt es auch Femtoclocks, dass hieße um schlappe drei Größenordnungen niedrigerer Jitter. Ich maße mir bei diesem Thema nicht die geringste Sachkompetenz an, aber wenn man das mal zu Ende denkt, bleibt dann nicht einfach eine mögliche Erklärung:
Unterschied zwischen Dante und nicht Dante ist eine Masterclock für den Datenverkehr
und
diese Materclock hat Jitter der deutlich höher ist als die Singxers und wer weiß nicht was da da noch kreucht und fleucht auf dieser Welt.
Kann es sein, dass es besser ist nur eine Masterclock zu haben als mehrere Clocks, selbst wenn die Clocks einen besseren Jitter haben als die eine Masterclock, sprich ist das delta (im Takt bzw. Jitter) zwischen mehreren selbst hochpräzisen Clocks schädlicher als der höhere Jitter einer nicht ganz so präzisen Masterclock? Das wäre ja ein Ding!
Wobei wie ich die Jitter-Ritter kenne, kommt ihr gleich auf die Idee, dass eine noch bessere Masterclock nochbeser klingt als eine recht einfache. Gut genug gibt es bei Euch ja nicht
Vielleichthaabe ich auch nur viel Unsinn erzählt, wäre nicht das erste und ist sicherlich auch nicht das letzte Mal.*
Gruß
Uwe
* Es irrt der Mensch, solange er strebt
"Elon Musk"failure is an option here. if things are not failing you're not innovating enough
Eine Clock über das Netzwerk ist auf jeden Fall DEUTLICH schlechter als die über die internen Clocks. Ich komme ja aus dem Bereich Video und da kriegt es kein Hersteller ohne zusätzliche Synchronisationsmassnahmen absolut framesynchron Videos abzuspielen auch hier wird noch immer über weitere Maßnahmen synchronisiert (wie z.B. Genlock)
Das Delay im Netzwerk kann durchaus mal in den Millisekunden Bereich driften. Deswegen, lässt sich ja bei Dante auch die Latenz bis in den zweistelligen Millisekunden Bereich einstellen.
Es wird dann, wenn ich das richtig verstanden habe, noch ein Zusätzlicher Timestamp mitgeschickt, der für das Zeitrichtige ausspielen sorgt.
Innerhalb des Gerätes muss also meiner Meinung nach noch irgendwo eine Clock generiert werden die für das tacktgenaue Ausspielen sorgt.
Viele Grüße
Christian
Hallo Uwe,
Dante besitzt keine Masterclock, wie wir sie als Wordclock kennen, weil dies innerhalb des Netzwerks sehr viel (zu viel) Bandbreite beanspruchen würde. Deshalb clockt sich jedes Gerät weiterhin selbst. Damit aber dennoch alle Geräte innerhalb des Dante-Netzwerks synchron laufen, wird alle 250 Millisekunden ein sehr kurzer Takt-Impuls (Timestamp) an alle beteiligten Geräte gesendet, der sie bei möglicherweise zwischenzeitlich erfolgten Abweichungen wieder ins richtige Timing bringt. Ob es exakt alle 250 Millisekunden oder alle 250,001 Millisekunden erfolgt, hat null Einfluss auf den Jitter der digitalen Komponenten. Die im Dante-Netzwerk laufenden Geräte bleiben also weiterhin der entscheidende Faktor für die Entstehung von Jitter. Nur der Übertragungsweg via Dante scheint wesentlich Jitter resistenter zu sein als z.B. via USB-Schnittstelle resp. -Kabel.
Kritisch sieht es m.E. dagegen an der Übergangsstelle zwischen Dante-Protokoll und Audio-Stream im PCM- oder sonstigem Format. Wenn eine Dante I/O-Box wie das Micromedia-Interface auf SPDIF (oder günstiger I²S) ausgibt, dann spielt eine Rolle, von welcher Qualität das SPDIF-Signal dann ist, d.h. wie gut die interne Clock des Interface arbeitet.
Wenn Bernd Peter sagt, dass die Audio-Qualität besser als über die USB-Strecke ist, dann verstehe ich das als Aussage darüber, dass das SPDIF-Clocking schon ziemlich gut sein muss. Darüber hinaus scheint es sich klanglich positiv auszuwirken, dass die USB-Strecke als weiterer jitterkritischer Übertragungsweg wegfällt.
Grüße
Fujak
Dante besitzt keine Masterclock, wie wir sie als Wordclock kennen, weil dies innerhalb des Netzwerks sehr viel (zu viel) Bandbreite beanspruchen würde. Deshalb clockt sich jedes Gerät weiterhin selbst. Damit aber dennoch alle Geräte innerhalb des Dante-Netzwerks synchron laufen, wird alle 250 Millisekunden ein sehr kurzer Takt-Impuls (Timestamp) an alle beteiligten Geräte gesendet, der sie bei möglicherweise zwischenzeitlich erfolgten Abweichungen wieder ins richtige Timing bringt. Ob es exakt alle 250 Millisekunden oder alle 250,001 Millisekunden erfolgt, hat null Einfluss auf den Jitter der digitalen Komponenten. Die im Dante-Netzwerk laufenden Geräte bleiben also weiterhin der entscheidende Faktor für die Entstehung von Jitter. Nur der Übertragungsweg via Dante scheint wesentlich Jitter resistenter zu sein als z.B. via USB-Schnittstelle resp. -Kabel.
Kritisch sieht es m.E. dagegen an der Übergangsstelle zwischen Dante-Protokoll und Audio-Stream im PCM- oder sonstigem Format. Wenn eine Dante I/O-Box wie das Micromedia-Interface auf SPDIF (oder günstiger I²S) ausgibt, dann spielt eine Rolle, von welcher Qualität das SPDIF-Signal dann ist, d.h. wie gut die interne Clock des Interface arbeitet.
Wenn Bernd Peter sagt, dass die Audio-Qualität besser als über die USB-Strecke ist, dann verstehe ich das als Aussage darüber, dass das SPDIF-Clocking schon ziemlich gut sein muss. Darüber hinaus scheint es sich klanglich positiv auszuwirken, dass die USB-Strecke als weiterer jitterkritischer Übertragungsweg wegfällt.
Grüße
Fujak
-
- Aktiver Hersteller
- Beiträge: 4666
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Sowohl bei USB als auch bei Dante werden die PCM-Daten nicht bitweise sondern als Datenpaket versandt. Das ist dann beim Empfänger zu speichern und passend für die Wiedergabe aufzudrisseln und zu takten. Insofern unterscheiden sich USB und Netzwerk nicht wirklich.Fujak hat geschrieben:Darüber hinaus scheint es sich klanglich positiv auszuwirken, dass die USB-Strecke als weiterer jitterkritischer Übertragungsweg wegfällt.
M.b.M.n. kann man aber davon ausgehen, dass Dante auf einem Ethernet mit einer galvanischen Entkopplung aufbaut, siehe z.B. https://www.audinate.com/products/dante ... etbox-4-mh. Was bei USB ja eher selten der Fall ist.
Grüsse
Uli
-
- Aktiver Hörer
- Beiträge: 4008
- Registriert: 04.05.2010, 19:37
Hallo,
ich verstehe micromedia sehr gut, wenn sie zur Markteinführung im HiFi Bereich Platinen zu bezahlbaren Preisen fertigen und anbieten, um die Leistungsfähigkeit dieser durchdachten Technologie bekannter zu machen.
Einer Optimierung in Teilsektionen steht nichts entgegen, man braucht dazu Wissen und Können. Und etwas mehr Geld.
Der Startschuß dürfte gefallen sein.
Gruß
Bernd Peter
ich verstehe micromedia sehr gut, wenn sie zur Markteinführung im HiFi Bereich Platinen zu bezahlbaren Preisen fertigen und anbieten, um die Leistungsfähigkeit dieser durchdachten Technologie bekannter zu machen.
Einer Optimierung in Teilsektionen steht nichts entgegen, man braucht dazu Wissen und Können. Und etwas mehr Geld.
Der Startschuß dürfte gefallen sein.
Gruß
Bernd Peter
-
- Aktiver Hörer
- Beiträge: 4008
- Registriert: 04.05.2010, 19:37
Hallo Andree,
du legst dich ja ordentlich ins Zeug, Respekt.
Gruß
Bernd Peter
du legst dich ja ordentlich ins Zeug, Respekt.
Im Netzwerkbetrieb ist für mich auf dem micromedia Board der gleiche Oszi für Musiktaktung und Upsampling zuständig. Da kann ich deshalb keine Asynchronität erkennen.Bezüglich asynchronem Upsampling schrieb Gert:
das Upsampling also asynchron erfolgt. Und das ist in der Realität eigentlich immer der Fall, wenn die Eingangsfrequenz und die Ausgangsfrequenz
durch unterschiedliche Quarzschwinger
festgelegt werden, deren Frequenzen immer eine gewisse Abweichung von der Sollfrequenz haben.
Gruß
Bernd Peter