ASIO und Clocking

play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Nun mal alles von vorne und systematisch der Reihe nach.

ASIO und Clocking ist durchaus mit einander eng verbunden !!!!

Takt : Ein Takt in der Technik (häufig auch Taktung) ist die Menge von Impulsen pro Intervall,bezogen auf ein Ereignis.
http://de.wikipedia.org/wiki/Taktsignal

Wordclock : Mit Hilfe des WordClock (auch Masterclock genannt) empfangen, senden und bearbeiten alle digitalen Geräte in der Kette die Datenströme synchron.
Synchron heisst Datenströme sind zu diesem Takt genau verpflichtet und beziehen sich auf diese Taktung.
Taktung und Clocking ist das selbe (Deutsch und Englisch jeweils)

Der Computer hat eine Wordclock, die Soundkarte hat eine Wordclock und auch ein DAC hat eine Wordclock.
Das Entschiedene für eine einwandfreie Übertragung ist dass nur eine dieser Wordclock´s die Referenztaktung für alle anderen beteiligten Elemente angibt.

ASIO bestimmt welche WordClock die Referenz ist (-oder kann es jedenfalls bestimmen).
Idealer Weise ist die WordClock ganz nahe am Wandlerchip, damit kein Jitter zwischen WordClock und Wandlerchip entsteht.

Um die Synchronisierung zu einer WordClock zu ermöglichen, müssen alle beteiligten Elemente dem Prinzip folgen, dass die Taktung auf einer Leitung erfolgt und dass das Musiksignal auf einer anderen (separaten) Leitung erfolgt.
Daher ist diese Übertragung als asynchron (also unabhängig) bezeichnet.

(es ist verwirrend das um eine synchrone Übertragung zu bekommen, muss man eine asynchrone Übertragungsweise benutzen !!!)

Die perfekte Übertragung von Player bis zum Wandlerchip ist also wenn die WordClock (physisch nahe am Wandlerchip) die ganze Übertragungskette bestimmt und möglichst präzise ist.
In dieser Architektur bedarf es dass die WordClock alle Elemente der Übertragung auch steuern kann, und genau deshalb muss die Taktung und das Musiksignal getrennt erfolgen.
Der Player sendet also nicht Daten; Daten werden von dem Wandlerchip über die WordClock abgerufen !
-und zwar Zeitgenau.

Wenn eine Soundkarte mit ASIO funktioniert, wird die Synchronisierung zwischen der WordClock dieser Karte und dem Player etabliert.
Die WordClock einer guten Soundkarte ist erheblich genauer als die WordClock des Computers.

Eine Soundkarte die dann ein digitales S/PDIF oder TosLink Signal ausgibt, überträgt von dort ab keine eine synchrone WordClock Taktung mehr.
-und somit muss eventueller Jitter im DAC entweder gesäubert werden (Re-Clocking) oder verbleibt im Signal und stört die D/A Wandlung.

Wenn nun ein externer DAC eine synchrone Taktung erlaubt, muss die Übertragung durch alle Kabel und Schnittstellen den asynchronen Modus unterstützen.
Prinzipiell kann S/PDIF diesen Modus nicht.
Da S/PDIF eine Coax Übertragung ist fehlt ein Kabelstrang für die separate Taktung einer asynchronen Übertragung.

Nun haben einige Hersteller von DACs ein Protokoll entwickelt wodurch ein asynchroner Modus über USB, AES/EBU, I2S oder FireWire möglich wird.
RME, Ayre, Wavelength u.A. haben Treiber für Ihre DACs dieser Art auf den Markt gebracht.
Der Vorteil ist eine saubere A-Z WordClock Übertragung ohne Re-Clocking Säuberung. In solcher Übertragung entscheidet nur die Genauigkeit der Taktung die ultimative Qualität. Diese Übertragung ist prinzipiell auch ASIO.



Re-Clocking ist eine effektive "Neuaufbereitung" eines verjittertes Signals.
In dieser Technik werden durch mehrere PLL´s (Phase Locked Loops) und ausgeklügelte proprietäre Schaltungen mit Spannungsgesteuerten Oszillatoren das Signal mehr oder weniger von Jitter befreit.
Diese Technik ist unumstritten sehr effektiv wenn hochwertig umgesetzt, aber es reduziert nur den Jitter proportional und entfernt ihn nicht.
Zudem ist diese Technik nicht ganz Preiswert.

Der gravierende Haken an einem KernelStreaming ist nicht nur das der Player den Takt des Computer verwendet, und dass das Signal hinzu auch noch durch einen Teil der Windows Sound Engine laufen muss, aber eklatant ist die fehlende Übereinstimmung eines Taktes.
Dies resultiert nicht nur in einer wesentlich erhöhten Latenzzeit, aber führt auch zu potentiellen Clock-skews bei der Anknüpfung zu anderen Audio Geräten (einer Soundkarte, einer HiFace oder einem DAC z.B.).
-und damit ist Jitter schon vorprogrammiert.


Viele Grüße

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

Beitrag von Fujak »

Hallo Leif,

aus meiner Sicht hast Du in Deinem letzten Beitrag wieder einige Aspekte miteinander verknüpft, die nichts miteinander zu tun haben (Wordclock hat nichts mit dem synchroner oder asynchronen Übertragung zu tun, ASIO nichts mit Taktung oder gar dessen Synchronisierung etc.).

Ich hatte ein paar Versuche unternommen, diese Dinge in der Diskussion zu trennen und getrennt zu halten, was mir offenbar nicht gelungen ist. Mittlerweile glaube ich nicht mehr, dass bei dieser Erörterung noch etwas vernünftiges herauskommt.

Ich klinke mich daher aus dieser Diskussion aus.

Grüße
Fujak
Bild
Fortepianus
Aktiver Hersteller
Beiträge: 3669
Registriert: 17.12.2008, 12:41
Wohnort: Stuttgart

Beitrag von Fortepianus »

Hallo Leif,
play-mate hat geschrieben:Nun mal alles von vorne und systematisch der Reihe nach.
ja, das ist gut! Und dabei bemerke ich ein paar Ungereimtheiten sowohl im Verständnis wie auch in den Begrifflichkeiten. Deshalb fange ich auch mal ganz vorne an, nämlich, wie das mit den verschiedenen Takten überhaupt funktioniert in einer Digitalkette. Vielleicht hilft das ja ein wenig zum Verständnis.
play-mate hat geschrieben:Idealer Weise ist die WordClock ganz nahe am Wandlerchip, damit kein Jitter zwischen WordClock und Wandlerchip entsteht.
Ganz nahe am Wandlerchip sitzt idealerweise die Masterclock. In einen DAC-Chip gehen üblicherweise vier Digitalleitungen. Hier ein typisches Beispiel für eine Abtastrate (Wordclock) von 44,1kHz:

1. Die Masterclock (11,2896MHz, der Haupttakt, aus dem alles andere abgeleitet wird)
2. Die Bitclock (2,8224MHz, besagt, in welchem Takt die Daten, also die Bits, kommen)
3. Die Wordclock (44,1kHz, besagt, in welchem Rhythmus es wieder von vorn losgeht, und steuert die links-rechts-Zuordnung)
4. Die Daten (Bits)

Die Bit- und die Wordclock werden, wenn der Mastertakt am DAC völlig autark arbeiten darf, durch Teilen (durch 4 bzw. durch 256) erzeugt. Das wird mit Flipflops gemacht, teilen durch Zweierpotenzen ist technisch einfach. Je mehr solcher Teilerstufen beteiligt sind, desto jitterbehafteter wird allerdings der Ausgangstakt. Deshalb ist bei guten DAC-Chips nicht die Wordclock, sondern die Masterclock für den Übersetzungszeitpunkt der digitalen Daten ins Analoge zuständig. Zum Beispiel so, dass nach der letzten negativen Wordclockflanke die übernächste positive Flanke der Masterclock zählt oder ähnlich.

Ist eine solche Masterclock mit zugehörigen Teilern am DAC implementiert, kann von hier rückwärts die Datenbeschaffung synchron gehalten werden. In einem CD-Player z. B. werden diese Takte verwendet, um das Auslesen zu synchronisieren, also Steuerung des Motors, der Zwischenspeicher, der Fehlerkorrektur etc.

Ist der Datenlieferant extern, muss eine Wordclock zurückgeführt werden, wenn man so arbeiten will. Dann muss aber der Datenlieferant, der auch wieder gerne eine Master-, Bit- und Wordclock hätte, sich darauf synchronisieren. Es genügt nicht, die Masterclocks synchron zu halten, denn sonst sind Anfang und Ende eines Datenwortes (das ist der 16-24Bit lange Wert des Musiksignals zu einem Zeitpunkt) nicht synchron. Es muss also die Wordclock synchronisiert werden. Das geht so: Es wird ein Mastertakt erzeugt, der in seiner Frequenz veränderbar ist. Aus diesem wird wieder durch Teilen die Bit- und Wordclock erzeugt. Nun vergleicht man diese Wordclock mit der empfangenen vom DAC. Kommt die Flanke vom einen später, gibt das proportional zur Zeitdifferenz eine positive Spannung, kommt der andere später, eine negative. Man vergleicht also die Phaselage dieser Taktsignale und erzeugt eine Ausgangsspannung, die diesen Vergleich repräsentiert. Mit dieser Spannung steuert man die veränderliche Masterclock, und die stellt sich durch den entstandenen Regelkreis so ein, dass die Wordclocks synchron werden. Alle anderen Takte, die Vielfache davon sind, sind dann automatisch auch synchron. Die Regelspannung wird übrigens noch tiefpassgefiltert, damit der zu synchronisierende Takt nicht jedes Zucken des Eingangstakts mitmachen muss. Was ich gerade erklärt habe, ist eine PLL (phase locked loop).

Der umgekehrte Fall geht auch und ist meistens anzutreffen: Die fixe Masterclock sitzt beim Datenlieferanten und der DAC oder sonstige dazwischen geschaltete Digitalgeräte synchronisieren sich auf die Wordclock des Lieferanten. Diese kann entweder separat übertragen werden oder durch eine bestimmte Struktur des Übertragungsprotokolls aus den Daten wieder rekontruiert werden wie bei AES/EBU oder S/PDIF. Bei der separaten Wordclock-Übertragung kann auch eine zentrale Wordclock zum Einsatz kommen, nach der sich alle Beteiligten richten (üblich in Studios).
play-mate hat geschrieben:Um die Synchronisierung zu einer WordClock zu ermöglichen, müssen alle beteiligten Elemente dem Prinzip folgen, dass die Taktung auf einer Leitung erfolgt und dass das Musiksignal auf einer anderen (separaten) Leitung erfolgt.
Daher ist diese Übertragung als asynchron (also unabhängig) bezeichnet.

Nein, da liegt ein Missverständnis vor. Synchronität bedeutet nicht mehr und nicht weniger, als dass alle den gleichen Takt haben. Dabei ist es völlig egal, ob Daten und Takt auf der gleichen oder auf verschiedenen Leitungen übertragen werden. Eine asynchrone Übertragung bedeutet, dass Sender- und Empfängertakt nichts voneinander wissen.
(es ist verwirrend das um eine synchrone Übertragung zu bekommen, muss man eine asynchrone Übertragungsweise benutzen !!!)
Nein, siehe oben.
play-mate hat geschrieben:Die perfekte Übertragung von Player bis zum Wandlerchip ist also wenn die WordClock (physisch nahe am Wandlerchip) die ganze Übertragungskette bestimmt und möglichst präzise ist.
Wie erläutert ist für den DAC die Präzision der Masterclock entscheidend. Damit die Daten selbst nicht durch Übersprechen der Taktungenauigkeiten die Performance des DACs verhunzen, müssen die Daten selbst auch möglichst jitterfrei sein. Dazu muss bei der betrachteten Übertragungsart der Lieferant aus der Wordclock eine möglichst präzise eigene Masterclock erzeugen. Das ist aber mit PLLs nur begrenzt möglich, egal, wie präzise die ankommende Wordclock ist.
In dieser Architektur bedarf es dass die WordClock alle Elemente der Übertragung auch steuern kann, und genau deshalb muss die Taktung und das Musiksignal getrennt erfolgen.
Der Player sendet also nicht Daten; Daten werden von dem Wandlerchip über die WordClock abgerufen !
-und zwar Zeitgenau.
So sieht das aus großer Flughöhe aus, ist im Detail aber nicht so - wie gesagt muss durch eine PLL die Synchronität hergestellt werden.
play-mate hat geschrieben:Wenn eine Soundkarte mit ASIO funktioniert, wird die Synchronisierung zwischen der WordClock dieser Karte und dem Player etabliert.
Die WordClock einer guten Soundkarte ist erheblich genauer als die WordClock des Computers.
...weshalb die Daten selbst zwar synchron geliefert werden, aber vom PC beliebig verwackelt angeliefert werden können, was dem DAC das Leben schwer machen wird. Kommt hier nun ein Gerät zum Einsatz, das die Daten neu taktet, kann eine erhebliche Steigerung der Wandlungsgenauigkeit im DAC erreicht werden.
play-mate hat geschrieben:Eine Soundkarte die dann ein digitales S/PDIF oder TosLink Signal ausgibt, überträgt von dort ab keine eine synchrone WordClock Taktung mehr.
-und somit muss eventueller Jitter im DAC entweder gesäubert werden (Re-Clocking) oder verbleibt im Signal und stört die D/A Wandlung.
Wie gesagt, überträgt das S/PDIF-Signal die Wordclock, und zwar selbstverständlich synchron, sonst könnte man sie weglassen.
play-mate hat geschrieben:Wenn nun ein externer DAC eine synchrone Taktung erlaubt, muss die Übertragung durch alle Kabel und Schnittstellen den asynchronen Modus unterstützen.
Diese Begrifflichkeit ist nach meiner Meinung unüblich, wie schon oben erwähnt. Ein asynchroner Modus ist z. B. bei USB etwas gänzlich anderes: Der USB-Empfänger hat einen Takt, der weder etwas vom Rechner weiß noch wissen will. Er ist völlig asynchron zum Takt im PC. Er liefert seinen Takt dem PC zurück, und es ist ihm egal, wie dieser es dann hinkriegt, die Daten mit dem zur Verfügung gestellten Takt zu liefern.
play-mate hat geschrieben:Prinzipiell kann S/PDIF diesen Modus nicht.
Richtig. Es läuft andersrum. Sender liefert Daten plus im Protokoll verpackte Wordclock.
play-mate hat geschrieben:Da S/PDIF eine Coax Übertragung ist fehlt ein Kabelstrang für die separate Taktung einer asynchronen Übertragung.
Dieser Satz war es eigentlich, der mich dazu brachte, die Erklärungen oben zu schreiben :cheers: . Ich hoffe, es wird nun klar, dass nach meinem Verständnis in diesem kurzen Statement zwei grundlegende Fehler stecken. Erstens ist die Übertragung der Inhalte nicht vom physikalischen Medium abhängig (Koax oder Licht oder Suchdirwasaus), sondern vom Protokoll. S/PDIF überträgt die Wordclock. Zweitens hat asynchrone Übertragung nichts mit Leitungen zu tun, sondern mit nicht im Gleichtakt arbeitenden Partnern.

Auf die darauf folgenden Schlussfolgerungen will ich nicht im Detail eingehen, denn es ist hoffentlich klar geworden, dass die Basis, auf der sie aufbauen, für mein Verständnis nicht ganz richtig ist.

Dabei kann digitale Signalübertragung so einfach sein. Ich beschreibe kurz, wie ich das mache. Dem Lieferanten gebe ich die bestmögliche Clock, die ich kenne. Dem DAC auch, und beide sind asynchron, wissen also nichts voneinander. Vor dem DAC sitzt ein asynchroner Sampleratenkonverter (ASRC), der auf beiden Seiten perfekte Takte sieht, sowohl vom DAC, wie vom Lieferanten. Zugegeben, das ist die Kurzfassung :mrgreen: .

Viele Grüße
Gert
Bild
vincent kars
Aktiver Hörer
Beiträge: 154
Registriert: 15.03.2011, 16:50
Kontaktdaten:

Beitrag von vincent kars »

Gert

Great write up

Thanks

Vincent
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Gert,

Vielen Dank für deinen Beitrag in diesem wirklich schwierigen Thread.

Ich kann nicht sehen dass wir prinzipiell uneinig sind, aber deine Sichtweise des Problems ist nicht richtig !
(oh ha, -nun risikiere ich wirklich den letzten Rest meiner Glaubwürdigkeit......)
-ich sage nicht dass du Falsch liegst, nur das deine Argumentation nichts mit ASIO zu tun hat.



Ein Computerplayer (Foobar, cPlay etc.) ist kein Streamer wie Sonos und ist auch kein CD Player.
So ein Player ist eine Software und liefert daher auch keine Daten von selbst.

Um Daten zu liefern muss er ein Protokoll haben und dazu gibt es schlicht 3 Wege :

1. über die Windows Sound Engine (inklusive K-Mixer)
2. über KernelStreaming (Asio4All, WASAPI, KS, WaveRT etc.)
3. über echtes ASIO.

In Fall 1 & 2 gibt der eingebaute Taktgeber des Computers die Genauigkeit des Signals an und lässt sich nicht von einem anderen Masterclock steuern. Wie genau dies passiert brauche ich nicht zu sagen....dieses Verfahren ist ein Streaming.

Im Falle ASIO, lässt dieses Protokoll genau zu, die Masterclock zu bestimmen. Dies sogar möglich wenn diese ausserhalb des Computers sitzt. ASIO ist kein Streaming. Bei ASIO holt sich die Hardware (Soundkarte oder DAC) sich die Daten ab, denn der Player ist ein Teil der Hardware !!!

Puhhh, -ist dass wirklich so schwierig zu verstehen ??

Mag sein dass es in meinem Versuch dies begreiflich darzustellen, eine Diskussion über konkrete Definitionen wie z.B. "WordClock" erfolgen könnte, aber bitte versucht es doch jedenfalls....

Mit erschöpften Grüßen

Leif
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Leif,

doch noch ein Wort zu ASIO und spdif. Der ASIO-Treiber ist eine Software. spdif ist ein Datenprotokoll. Dazwischen gibt es jedoch noch Hardware. Der bei spdif verwendete Biphase-Mark-Code wird NICHT durch den ASIO-Treiber erzeugt, sondern durch entsprechende Chips.
Wie das z.B. abläuft lässt sich schön nachlesen hier, was erstmal nichts mit PC und ASIO zu tun hat. Wie dann dort in Bild 4 zu sehen ist, geht dazu ein Clocksignal auf den Chip. Das bedeutet, dass zwar die Daten rechtzeitig ankommen müssen, aber die Clock den Takt angibt. Nicht eine Software.

Und das ist bei üblichen Soundkarten auch nicht anders.

:cheers:

Grüsse, Uli
Bild
Heule
Aktiver Hörer
Beiträge: 857
Registriert: 27.02.2010, 14:35

Beitrag von Heule »

Fortepianus hat geschrieben:Dabei kann digitale Signalübertragung so einfach sein. Ich beschreibe kurz, wie ich das mache. Dem Lieferanten gebe ich die bestmögliche Clock, die ich kenne. Dem DAC auch, und beide sind asynchron, wissen also nichts voneinander. Vor dem DAC sitzt ein asynchroner Sampleratenkonverter (ASRC), der auf beiden Seiten perfekte Takte sieht, sowohl vom DAC, wie vom Lieferanten. Zugegeben, das ist die Kurzfassung.
Danke lieber Gert für deine Antwort/Erklärung. Bin ja meistens hier nur stiller Mitleser, weil ich
hier zum lernen bin, und mich nicht blamieren will :lol:
Bei dir hat man immer das Gefühl, das alles ganz einfach ist. Du hast eine ganz eigene Denkweise
an Sachen heranzugehen, die für mich sehr faszinierend ist. Von solchen Menschen wie dir kann man einfach
nur lernen und staunen. Danke.

Gruß Oliver.
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Uli,

ASIO IST ein Protokoll.
Erster Satz bei Wikipedia :

"Audio Stream Input/Output (ASIO) ist ein vom Audio-Spezialisten Steinberg entwickeltes, mehrkanalfähiges Audiotransfer-Protokoll."

-und um dieses Protokoll ausführen zu können, bedarf es einen Software-Treiber.
Hat doch nichts mit S/PDIF zu tun....(habe ich doch schon x-mal betont).

Das ASIO Protokoll sieht auch vor welche Masterclock verwendet werden soll.
Z.B. in deiner FireFace kann wenn über ASIO betrieben, diese Verwendung eingestellt werden.
Von der RME Bedienungsanleitung :

Clock Mode Sample Rate Setzt die aktuell verwendete Samplefrequenz. Bietet eine zentrale und komfortable Möglichkeit, die Samplefrequenz aller WDM-Devices auf den gewünschten Wert zu stellen, denn seit Vista ist dies nicht mehr über das Audioprogramm möglich. Ein ASIO-Programm kann die Sample- frequenz jedoch wie bisher selbst setzen.
Bei laufender Wiedergabe/Aufnahme ist die Auswahl ausgegraut, eine Änderung nicht möglich.
Clock Source
Das Gerät kann als Clock-Quelle seine eigene Clock (Internal = Master) oder eines der Ein- gangssignale (Word, Optical, SPDIF coax., LTC) verwenden. Steht die gewählte Clock-Quelle nicht zur Verfügung, wechselt das Gerät automatisch zur nächsten verfügbaren (AutoSync). Steht keine zur Verfügung wird die interne Clock benutzt. Die aktuell verwendete Clock-Quelle wird rechts angezeigt.


....auch hier kann entnommen werden dass "Word, Optical,S/PDIF coax.LTC" die Clock des RME nicht verwenden kann.

Sorry für meine Beharrlichkeit in dieser Sache, aber Computer Audio ist nun mal anders als Geräte mit Kabel zu kombinieren.

Viele Grüße Leif
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Hallo Leif,

auch ich kann beharrlich sein :-)
Wir brauchen eigentlich nicht darüber zu diskutieren, was denn ASIO ist. Ein ASIO-Treiber ist ein Stück Software, welches eine definierte Schnittstelle zwischen Anwenderprogramm und Soundkarte aufbaut. Daneben gibt es noch weitere Regelungen für den Austausch von Informationen. Die Abwicklung des Datenaustausches läuft über ein Protokoll, hier eben I/O-Buffer mit Bufferswitch.

Zur Soundkarte hin ist ASIO nicht weiter spezifiziert, es hängt ja davon ab was die Soundkarte für Eigenschaften hat. Das kann jeder Hersteller machen wie er will. Und so unterscheidet sich auch jedes Benutzer-Interface von einer Soundkarte zur anderen.

Natürlich teilt man dem ASIO-Treiber auch mit z.B. welche Taktfrequenz man verwenden möchte, der Treiber sagt auch, welche Frequenzen die Soundkarte kann. Und woher soll der Treiber denn von alleine wissen, dass das Stück, welches man spielen möchte, nun genau 88.2 kHz hat. Das ist aber bei einem WDM-Treiber auch nicht anders.

Soweit alles gut.

Doch was ist denn nun Deine eigentliche Botschaft bzgl. ASIO? Wir wissen, dass der Treiber am Kernel vorbeigeht (wie das genau erfolgt, weiss ich nicht. Auch nicht wie das mit Windows-Kernel-Richtlinien vereinbar ist). Wir wissen, dass ASIO von beliebigen Playerprogrammen genutzt wird. Was aber immer noch nicht bedeutet, dass die Ausgabe jitterfrei ist. Dass also mehr dazu gehört, was ja cmP² z.B. versucht.

Finally, der ASIO-Treiber endet auf der Soundkarte ebenfalls ein Stück vor der eigentlichen Ausgabe. Dazwischen kommt noch entsprechende Hardware, welche dann die Daten schnittstellengerecht aufbereitet. Dies mögen auch irgendwelche Gatter sein, die dann das jeweilige Clocksignal für den Takt durchschalten. Keinesfalls wird über ASIO ein Bit an- und ausgeschaltet, um damit dann einen Takt zu erzeugen.

Mit all dem beschriebenen Hintergrund: was ist bitte nochmal der Kern Deiner Botschaft, speziell im Hinblick auf Vor- und Nachteile ? Vielleicht reden wir aneinander vorbei. Noch hab ich Dich nicht verstanden.

Grüsse, Uli
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Uli,

ich fühle mich in dieser Sache wirklich wie Don Quixote gegen die Windmühlen...

Also meines Erachtens sprechen wir doch über ASIO, oder ??

Der Kern dieses Threads ist ASIO und Clocking, und der Punkt ist dass das ASIO Protokoll vorgeben kann an welcher Clock die Audioübertragung seinen Referenztakt bekommt, und dass sich Windows sich raushalten soll.

Dies ist die Essenz des ganzen.

Dann kamen wir auf Fujak, Kernelstreaming und was Windows für einen Unsinn in diesem Bezug macht.
-und wir kamen auf Synchronisierung.
Die Diskussion fing an zu schnurren.....


Meine Botschaft ist dass ASIO das richtige Protokoll, und einzig Vernünftige ist um Audio von einem Computer auf einen DAC zu bekommen.
Alles andere sind Kompromisse für die man eine kostspielige Säuberung mit Re-Clocking braucht.
Punkt.


Nun wird hier so argumentiert als ob ein Computer ein Zuspieler (Streamer oder CD Player) ist und daher ASIO keine Relevanz hätte.
Als Zuspieler ist ein Computer eine denkbar schlechte Wahl weil sich Windows einmischt und die Taktung des Players hierbei vom PC gesteuert wird.
-das Ergebnis ist viel Jitter.

Der richtige Weg ist ASIO, denn (laut Protokoll) umgeht ASIO nicht nur Windows (WDM), aber legt auch die Masterclock fest.
Im idealen Fall im DAC selber.
Dazu braucht man aber eine asynchrone Übertragung.
Wenn dies alles gegeben ist, bestimmt diese Masterclock die Präzision womit der Wandlerchip läuft.

-und wenn diese Masterclock präzise ist, erübrigt sich ein Re-clocking.


So, jetzt lass es euch dies auf der Zunge zergehen und liest den Thread noch mal.
Es könnte ja sein dass der Groschen fällt....

Vile Grüße Leif
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

play-mate hat geschrieben: ich fühle mich in dieser Sache wirklich wie Don Quixote gegen die Windmühlen...
Ich verlier immer wieder den Faden, es wogt hin und her in der Diskussion.
play-mate hat geschrieben:Also meines Erachtens sprechen wir doch über ASIO, oder ??
ich hoffe es inständig
play-mate hat geschrieben: Der Kern dieses Threads ist ASIO und Clocking, und der Punkt ist dass das ASIO Protokoll vorgeben kann an welcher Clock die Audioübertragung seinen Referenztakt bekommt, und dass sich Windows sich raushalten soll.
ASIO kann vorgeben, ob eine Soundkarte sich auf einen Signaleingang synchronisiert (im Fall Digitaleingang), oder sich auf eine Wordclock sync't (sofern die Soundkarte überhaupt eine Wordclock zulässt), oder mit welcher interner Taktrate gearbeitet wird (im Fall analoger Signale). Was anderes kann ich dem Steinberg ASIO-SDK Manual nicht entnehmen.
Jedoch: das können auch alle anderen Treiber, ob WDM oder ALSA. Es wird von der vorgefundenen Hardware, sprich Soundkarte abgefragt, was sie leisten kann. Und dann wiederum können die Treiber die beschreibbaren Eigenschaften vorgeben, also auch die Clock setzen.
play-mate hat geschrieben: Meine Botschaft ist dass ASIO das richtige Protokoll, und einzig Vernünftige ist um Audio von einem Computer auf einen DAC zu bekommen.
Alles andere sind Kompromisse für die man eine kostspielige Säuberung mit Re-Clocking braucht.
Punkt.
Widerspruch bezgl. Re-Clocking: ASIO vermeidet unvorhersehbare Mix- und Konvertierungsvorgänge, da es nicht die Kernelroutinen nutzt. Mehr nicht. Beispiel: eine wav wird von der Festplatte abgespielt. Die Datei gibt die Samplerate vor. Das wird dem ASIO-Treiber mitgeteilt. Und auch, dass am spdif-ausgang rausgegeben wird. Der Treiber empfängt die Daten und bereitet sie für die Soundkarte auf. Irgendein Chip auf der Soundkarte macht letzlich das spdif-Signal daraus. Mit einer Clock, die von einem Quartz auf der Soundkarte abgeleitet ist.
Was nun, wenn der Quartz nichts taugt? Da weiss ASIO nichts drüber. Keinerlei Kontrolle. Ich geh mal davon aus dass auf Soundkarten keine Atomuhren drauf sind.

Und schon kann es Sinn machen, das spdif-Signal zu re-clocken. Oder eine ASRC einzusetzen. Was auch immer die Taktqualität verbessert.
play-mate hat geschrieben: Nun wird hier so argumentiert als ob ein Computer ein Zuspieler (Streamer oder CD Player) ist und daher ASIO keine Relevanz hätte.
Als Zuspieler ist ein Computer eine denkbar schlechte Wahl weil sich Windows einmischt und die Taktung des Players hierbei vom PC gesteuert wird.
-das Ergebnis ist viel Jitter.
Nein, es bezweifelt hier keiner ASIO. Es ist besser als die Windows-Treiber und daher gibts in meinem Programm auch nur ASIO. Anders als z.B. bei ARTA oder HolmImpulse.
Aber ASIO macht alleine eben auch nicht glücklich und vor allem nicht jitterfrei. Sonst, wie schon mal geschrieben, müssten Foobar, JRiver, cmP² und alle anderen Player sich mit ASIO identisch anhören.
play-mate hat geschrieben: Der richtige Weg ist ASIO, denn (laut Protokoll) umgeht ASIO nicht nur Windows (WDM), aber legt auch die Masterclock fest.
Im idealen Fall im DAC selber..
Nein, es wird nur vorgegeben, was die Soundkarte als zulässig akzeptieren würde, was sie eben kann.
play-mate hat geschrieben: Dazu braucht man aber eine asynchrone Übertragung.
Wenn dies alles gegeben ist, bestimmt diese Masterclock die Präzision womit der Wandlerchip läuft.
Das klappt, wenn die Soundkarte hardwareseitig eine asynchrone Schnittstelle aufweist. Dann ist sie auch anwählbar. Das wiederum können aber auch alle Treiber tun, nicht nur ASIO.
play-mate hat geschrieben:-und wenn diese Masterclock präzise ist, erübrigt sich ein Re-clocking.
Neben der Clock auf der Soundkarte kommt danach ja noch die physikalische Leitung. Bei spdif das Thema 75 Ohm Wellenwiderstand, Reflektionen bei falscher Anpassung etc. Dann hilt auch keine Atomuhr auf der Soundkarte.

Grüsse, Uli
Bild
Henryk
Aktiver Hörer
Beiträge: 73
Registriert: 29.12.2010, 18:58

Beitrag von Henryk »

Hallo zusammen,

gerade habe ich das Thema, zum ersten mal, durchgelesen. Was für eine Lektüre für einen Morgen/Vormittag...

Selbst wenn ich nur die Hälfte verstanden haben sollte, dann ist dieses Thema wieder für viele Laien/Anfänger und stille Mitleser richtig Gold wert.

Beim Lesen kam das Gefühl auf, dass beide "Partien" richtig liegen. Hier werden aber irgendwie zwei verschiedene „Konzepte“ besprochen:
Klassisch: Fujak, Uli, Gert. Hier versucht man aus klassischer Sicht die Kette zu optimieren. Damit auch den PC als Zuspieler.
Neu (aus Sicht von HiFi): Leif. Hier wird aus DAC und PC via ASIO eine Einheit (Damit gelten etwas andere Regeln als bei der klassischen Kette).

Wie geschrieben, glaube ich nicht genug Ahnung zu haben, um produktiv was beizutragen. Für Verwirrung will ich auch nicht sorgen.
Jedoch hoffe ich, dass ihr weiter macht, denn von solchen Themen profitieren viele Andere auch (u. a. meine Wenigkeit :-).

Wie gesagt, ist nur so ein Gefühl was bei mir aufkam.

Danke und viele Grüße,
Henryk

PS: Wie Winfried schon sagte, vielleicht wären Bilder verständlicher ;-)
PPS: Sehe gerade die letzte Antwort von Leif geht auch in die Richtung. Tja, doch erst Schreiben und nicht einkaufen gehen...
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3996
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo,

hier mal ein Auszug aus der readme Datei des Treibers für das Fireface UC:

Erläuterung zu den Treiberdateien:

fireface_usb.sys: Windows Hardware Treiber, WDM Audio ud MIDI
fireface_usb_64.sys: Windows 64 Bit Hardware Treiber, WDM Audio und MIDI
firefaceusb.exe: Settingsdialog
firefaceusbmix.exe: TotalMix
fireface_usb_asio.dll: ASIO Treiber
fireface_usb_asio_64.dll: 64 Bit ASIO Treiber
fireface_usb.cat: Katalog File für signierte Installation
fireface.inf: Hardware Installationsanweisung für Windows
TotalMixFX.exe: TotalMix FX for Fireface UFX
TotalMixFX.chm: Help file for TotalMix FX

Das RME-Programm TotalMix erlaubt die individuelle hardwaremäßig vorgegebene Clocksteuerung!

Alles andere kann Herr Daniel Fuchs von RME bei Bedarf noch genauer erklären.

Gruß

Bernd Peter
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3996
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo,

jetzt bin ich doch eine Zeile zu tief gerutscht.

Die Clockwahl erfolgt über die RME-DSP-Settings, das ist die firefaceusb.exe: Settingsdialog.

Gruß

Bernd Peter
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Henryk,

Danke für deinen wichtigen Beitrag zum Verständnis.

Es ist richtig dass es diese zwei Sichtweisen des Problems gibt.
Nun ist aber eher das ASIO dass "klassische" Konzept und die Sichtweise von Gert, Fujak, Uli und so manchen anderen, das "Neuere".

ASIO wird schon viel länger im Profibereich verwendet. Zurecht ist dieses Protokoll das erheblich effektivere, genauere und hörbar hochwertigere für Computer Audio !

Das ganze hin und her mit KernelStreaming, Hiface, teurere Re-Clocking Konzepte ist nur um den Konsummarkt ein relativ besseres Resultat mit der universellen USB Schnittstelle zu bieten, anstatt das Problem Jitter an der Wurzel anzupacken.

Das ein Steaming Client wie Sonos, Squeezebox, Linn usw. eine völlig andere Übertragung von Daten hat als ein Windows Computer ist so manchen gar nicht klar.
Gert´s optimierter Sonos ist zweifellos viel Jitterfreier als es jemals mit einem KernelStreaming möglich ist, nur hat ein Computer wiederum viele andere Vorzüge.
-das Abspielen von nativen 192kHz Dateien; digitale Frequenzweichen, Upsampling mit cPlay und eine einfache, integrierte Acourate Einbindung zum Beispiel.

Daher doch dieser Thread !
Bild
Antworten