ASIO und Clocking

Franz
inaktiv
Beiträge: 4422
Registriert: 24.12.2007, 17:07
Wohnort: 53340 Meckenheim

Beitrag von Franz »

Es zeigt mir insgesamt, dass die gesamte digitale Signalkette eine richtige Mimose ist, die gewissenhaft und pfleglich behandelt werden muss, damit das Ergebnis am Ende sauber ist. Auch scheint mir nach meinen bisherigen Erfahrungen, dass der Aufwand höher ist als bei einer rein analogen Kette, um ein ähnlich gutes oder gar besseres analoges Ergebnis hinter dem Wandler zu erzielen.
Unterschreibe ich nach jahrelangem Bemühen, eine saubere digitale Kette hinzubekommen, sofort.

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

Beitrag von play-mate »

Hallo Uli,

Verstehe nicht (?)....mein Bezug zu bunten Bildern ist weil cMP2 keine Bilder Bibliothek unterstützt. Das Foobar und die meisten anderen Player mit ASIO laufen können ist doch nichts neues.


Aber der Knackspunkt ist mittlerweile das Fujak sich in eigene Wiedersprüche im Bezug zu cMP, Player, Schnittstellen und Re-clocking verrennt.

Meine These ist nach wie vor das eine ASIO Übertragung für eindeutige Verhältnisse sorgt, und dass der Umweg über HiFace, KernelStreaming und BigBen Re-clocking eine unnötig teuere Lösung ist.

Mit einem Computer der eine genügende Prozessorleistung (SSSE4) für cMP2 und die asyncrone RME USB-ASIO oder eine direkte FireWire Schnittstelle hätte, ist meine Behauptung dass der BigBen und HiFace so relativ überflüssig wäre.....
Alternativ könnte man auch die cMP2 Lösung mit einem Apogee Rosetta 200 (oder was Vergleichbares) über S/PDIF vorstellen.
...insofern muss man natürlich auf die bunten Bilder verzichten.

Ich habe das Gefühl dass man so entweder eine preiswertere, oder eine hochwertigere Lösung erzielt.
Diese These wird in einigen von Fujak´s eigenen Aussagen angedeutet.

(....just my 2 cents)


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

Beitrag von uli.brueggemann »

Hallo Leif,

für mich ist die Diskussion ebenfalls etwas (wenn nicht mehr) verworren.
Ausgangspunkt ist doch, dass Du die ASIO-Schnittstelle hoch hängst. Ok?
Nun, wenn das denn optimal wäre, so müsste auch cmP mit ASIO, Foobar mit ASIO oder auch Acourate mit ASIO optimal sein. Und ASIO ist ja zumeist verfügbar, so sollte es keine Probleme geben.

Allerdings macht cmP ja noch weitere Ansätze drüber hinaus, beispielsweise Beenden unnötiger Windows-Dienste. Demzufolge ist ASIO nach wie vor logisch gesehen bezüglich der klanglichen Seite beeinflussbar. Oder nicht? Dann bräuchte es ja cmP nicht.

Für mich folgt daraus: ASIO ist vielleicht ein prima Baustein zum heiligen Audio-Gral, aber nicht das Einzige. Es steht im allgemeinen zur Verfügung und es ist auch einfach nutzbar.
ASIO wäre für mich sofort DIE EINZIGE Lösung, wenn mit ASIO egal wäre, was denn da für ein Player davor hängt und wie das Betriebssystem konfiguriert, getweakt und optimiert ist.

Stimmen wir beide in diesem Punkt soweit überein?

Wenn nun aber abhängig vom Player und Betriebssystem trotz bitgenauer Ausgabe über ASIO ein unterschiedlicher Klang entsteht, dann muss Jitter vorhanden sein. Demzufolge könnte ein Reclocking der ASIO-Ausgabe hilfreich unterstützen.

Was wäre an dieser Logik falsch?

Grüsse, Uli
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

@Uli: danke für Dein letztes Posting; das bringt es für mich auf den Punkt. Für mich ist der Titel des Threads auch insofern irreführend, als er suggeriert, es gäbe einen Zusammenhang zwischen der ASIO-Schnittstelle und Clocking. Was das Thema Jitter anbelangt, so ist nur letzteres, das Clocking, von entscheidender Bedeutung.

@Leif: Um ein sauberes Clocking hinzubekommen, braucht es kein ASIO. Nun funktioniert cmp² halt nur mit ASIO, doch auch wenn man einen simplen Platzhalter, nämlich das ASIO4All einsetzt und auf SPDIF routet, spielt cmp² seine klanglichen Vorzüge aus (so zumindest bei meinen Versuchen damit).

Umgekehrt haben meine Hörvergleiche ergeben, dass Foobar genauso gut oder schlecht klingt, egal ob man dessen Ausgabe über ASIO (über entsprechendes foo_asio.dll-PlugIn) oder über Direct Sound (in der bitgenauen Konfiguration natürlich!) laufen lässt.

Und deshalb ist es für mich nun auch müßig, weiter über einen Zusammenhang von ASIO und Clocking zu diskutieren, den es für mich weder in der Theorie noch im praktischen Hörvergleich gibt.

Der Rest der Diskussion betrifft dann eher Vor- und Nachteile von zwei verschiedenen grundlegenden Wegen, jitterminimiert zu hören (cmp² und Alternativen <-> Reclocking mit Big Ben oder Alternativen). Für mich bleiben es zwei ebenbürtige Wege für die PC basierte Audio-Wiedergabe.

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

Beitrag von uli.brueggemann »

Fujak hat geschrieben: doch auch wenn man einen simplen Platzhalter, nämlich das ASIO4All einsetzt und auf SPDIF routet, spielt cmp² seine klanglichen Vorzüge aus
Wobei für mich ASIO4All ja kein richtiger ASIO-Treiber ist (wozu bräuchte es denn sonst dieselbigen auch :) ), sondern eine ASIO-Schnittstelle mit den Doppelpuffern und dem Bufferswitch für den Datenaustausch mit einer ASIO-Anwendung nachbildet, intern dann aber über die Standard-Windows-Schnittstelle mit der Soundkarte kommuniziert ...

Grüsse, Uli
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo Uli,

deshalb bezeichnete ich ASIO4ALL als simplen Platzhalter. Und genau weil es kein echtes ASIO bietet, ist ja überhaupt erst der Vergleich möglich gewesen, ob ASIO tatsächlich zu einer Klangverbesserung bei der Audio-Wiedergabe führt - was es in meinem Setup nicht tut (sofern man Windows Direct Sound auf bitidentische Wiedergabe konfiguriert).

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

Beitrag von play-mate »

Hallo Uli,

Nichts ist an deiner Logik direkt falsch !

Re-clocking ist und bleibt eine wertige Lösung um Jitter aus einem Signal zu reduzieren (aber nicht ultimativ zu entfernen).
Die Technik des Re-clocking ist mittels doppelter PLL und einem genauen Spannungsgesteuerten Oszillator (siehe hierzu Gert´s Sonos Thread & Wikipedia) nur eine Nachbesserung wenn man schon ein verjittertes Signal hat.

Wenn das Signal vom Player durch KernelStreaming erst vom Windows PC getaktet wird, entsteht schon hier erheblicher Jitter.
Den versucht HiFace dann (als Spannungsgesteuerten Oszillator) zu minimieren.
Da dieser seinen Strom von der USB Schnittstelle bezieht, wundert es kaum dass wenn man HiFace eine andere externe Stromversorgung verpasst, sich das Signal dann verbessert.
Das HiFace muss Fujak aber verwenden um aus dem Netbook eine S/PDIF Schnittstelle zu ermöglichen.
Wenn dann das Signal in den BigBen Re-clocker geht, durchläuft dieses nun die zwei PLL´s und wird nochmals durch den Internen Oszillator des Apogee wieder neu getaktet.

Dies ist alles ein erheblicher (teurer) Aufwand um an ein sauber getaktetes Signal zu kommen.

Mit ASIO würde die Clock des RME direkt mit dem Player kommunizieren, ohne dass das Signal immer wieder neu zu Takten. Die Qualität würde dann allein die Clock (und PLL´s) des RME sein.
(theoretisch übrigens auch so, egal ob ein BigBen Re-clocker davor wäre oder nicht).

Der Clou dürfte aber sein einen DAC mit eigenem, hochwertigen PLL/Reclocking und ASIO zu betreiben, dann ist der Einfluss von Jitter des Computers durchaus gemindert. Ich betone gemindert, weil PLL/Reclocking nicht Jitter völlig entfernt, aber nur prozentual mindert. Wie effektiv diese Technik arbeitet ist unterschiedlich, aber Clock-Genauigkeit ist entscheidend und so was kommt nicht zum Null-Tarif.

Der Ansatz von cMP ist den Computer (mit dem avancierten Interpolations Upsampling von cPlay) von Jitter an der Quelle zu befreien, und damit auch eine vernünftige Basis für weniger Re-Clocking zu schaffen.
-damit ein DAC ( auch unterhalb der 1000 Euro Schwelle) ein möglichst Jitterfreies Signal bearbeiten kann.

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

Beitrag von play-mate »

Hey Fujak,

-nichts für ungut, aber ein KernelStreming mit mehreren Taktgebern in einem Setup mit echten ASIO gleichzusetzen finde ich dreist.
Jeder Studio-/Tontechniker würde sich tot lachen..... :shock:

Leif
Bild
frmu
Aktiver Hörer
Beiträge: 872
Registriert: 07.02.2011, 16:34
Wohnort: Berlin-Friedrichshagen

Beitrag von frmu »

Mit ASIO würde die Clock des RME direkt mit dem Player kommunizieren, ohne dass das Signal immer wieder neu zu Takten. Die Qualität würde dann allein die Clock (und PLL´s) des RME sein.
(theoretisch übrigens auch so, egal ob ein BigBen Re-clocker davor wäre oder nicht).
Hallo Leif,

ich nutze einen Audio-PC mit Foobar per USB ------> über ASIO an den Fireface UC (mit Labornetzteil) ... mehr nicht.
Wenn ich Deine Ausführungen richtig verstanden habe, ist dieses Vorgehen völlig ok?!


Gruß
Frank
Bild
wgh52
Aktiver Hörer
Beiträge: 5623
Registriert: 25.01.2008, 15:17
Wohnort: Schweitenkirchen
Kontaktdaten:

Beitrag von wgh52 »

Leif,

ich glaub' wir drehen uns hier irgendwie im Kreis...

Sind wir uns wenigstens einig was Jitter ist? Nach meinem Verständnis: Durch Einflüsse von Kabeln, Versorgungsunsauberkeit oder thermisch verursachtes Phasenrauschen eines Oszillatorausgangssignales oder eines seriellen Takt/Datenstromes.
play-mate hat geschrieben:Das HiFace muss Fujak aber verwenden um aus dem Netbook eine S/PDIF Schnittstelle zu ermöglichen.
Nicht ganz richtig, das geht auch mit Fireface UC.
play-mate hat geschrieben:Der Clou dürfte aber sein einen DAC mit eigenem, hochwertigen PLL/Reclocking und ASIO zu betreiben, dann ist der Einfluss von Jitter des Computers durchaus gemindert.
play-mate hat geschrieben:Der Ansatz von cMP ist den Computer (mit dem avancierten Interpolations Upsampling von cPlay) von Jitter an der Quelle zu befreien, und damit auch eine vernünftige Basis für weniger Re-Clocking zu schaffen.
-damit ein DAC ( auch unterhalb der 1000 Euro Schwelle) ein möglichst Jitterfreies Signal bearbeiten kann.
Also das verwirrt mich jetzt total! Ich denke mit ASIO, cMP² und asynchron USB gibt's keinen PC Jitter und Reclocking wäre unnötig!!

Mal folgendes Szenario:
Wir nehmen jetzt kein HiFace, sondern ein Fireface UC (kostet unter 1.000 € :wink: ), welches bekanntlich USB zur Übertragung zum und vom PC verwendet und intern getaktete DA Wandler bietet. Wenn man dieses mit dem echten ("entjitternden?") ASIO betreibt, müsste sich doch schon eine Verbesserung ergeben, denn da sind keine synchronisierenden PLLs dazwischen. Ob das Fireface die Daten über USB selber "hereintaktet" weis ich zwar nicht (glaube ich auch nicht), aber selbst wenn nicht müsste Verbesserung bemerkbar sein. Man könnte bei RME ja auch diese asynchrone Betriebsart mal anregen...

Gruß,
Winfried

PS: Ansonsten bin ich kurz davor wegen eigener Inkompetenz zu kapitulieren - "ich blick' das alles hier einfach irgendwie nicht"... :roll:

1701
Bild
analog+
Aktiver Hörer
Beiträge: 102
Registriert: 04.02.2011, 11:40

Beitrag von analog+ »

Hallo Fujak,

ich bin jetzt doch etwas verwirrt:
Da hattest seinerzeit eine Konfiguration aus Netbook-RME-Dac (Setup3.) als besser eingestuft als eine mit M2Tech und BigBen dazwischen (Setup 2).
Dann hattest Du geschrieben, dass diese Version (2) doch besser sei, weil die Playerunterschiede da keine Rolle mehr spielten.

Daß Du mit der Stromversorgung für M2Tech und RME nun exakter hören kannst ist völlig klar. Und das das M2Tech mit BigBen (mit oder ohne die Stromversorgung) immer besser klingt als ohne ihn ist eigentlich auch logisch.
Und klar ist doch auch, dass der Einsatz einer linearen Stromversorgung grundsätzlich auch dem RME guttut, in jedem Setup (also auch in Deinem alten Setup 3).

Was nun?
Es ist natürlich der PLL des BigBen nicht egal, was vor ihr passiert: Es spielt natürlich eine Rolle, wie sauber das ihm zugespielte Signal ist.
Ich sehe das schon so, ein jitterarmer, leistungsfähiger PC direkt asynchron an einen guten Dac gekoppelt bringt die bessere und vermutlich auch preiswerterere Lösung. Und da ist das Potential auch zu aufwändigeren Rechenoperationen ohne zwingenden Verlust an Klangqualität einfach da.
Weiterhin sollte man die die Potentiale der Player ausschöpfen zumal wenn ein Setup läuft, was mehr zu Gehör bringt – die von Dir seinerzeit durch den BB als nivelliert gehörten Unterschiede könnten durchaus wieder auftauchen.
Denn meine Erfahrung ist es, dass es keineswegs egal ist welcher Player läuft. Das müsste auch hinter dem BB noch zu hören sein.

Spaßeshalber könnte man so einen Low-Jitter-PC dann ja auch mal vor M2Tech und BB hängen. Denn wenn schon die M2Tech Stromversorgung so durchschlägt, dürfte das der Hammer sein...
(Ich hoffe in Bälde wieder an einen BB zu kommen, dann werde ich das mal ausprobieren).

Aus technischer Sicht hat es sich mir übrigens nie so recht erschlossen, warum Du ausgerechnet einen Asus EE-PC einsetzt. Eine leistungsfähigerere Plattform böte Dir sicherlich mehr Flexibilität und Möglichkeiten zum Experiment als diese.


Hallo Uli,

Asio alleine ist ein Stück Software, ein Treiber, der ohne PC und Dac gar nichts macht.
Und er muß spezifisch an den jeweiligen Dac angepasst sein. Die erzielbare Qualität hängt ab von der Qualität des Dac und der Programmierung des Treibers.

Die Idee, Asio mit Reclocking zu verbinden klingt reizvoll, dürfte aber ohne weiteres kaum funktionieren:
Denn der Dac sieht in unserem Fall den BB und nicht mehr den PC auf den er direkt zugreifen müsste - der BB ist kein Dac.
Andernfalls: Wenn der BB Dac-Funktionalität erhielte, könnte er mit dem passenden Treiber den PC steuern.
Doch dann kann man doch dafür gleich den richtigen Dac nehmen, denn der kann das ohnehin. Er muß halt eine gute Clock haben.


Hallo Wilfried,

exakt diese asynchrone Übertragung kann der RME FF-UC über USB. Dafür verwendet der RME seinen Asiotreiber. Diese Konfiguration entspricht Fujaks Setup 3.


Viele Grüße
Roland
Bild
Unicos
Aktiver Hörer
Beiträge: 805
Registriert: 22.06.2008, 20:38
Wohnort: NRW

Beitrag von Unicos »

Hallo,

mal eine Frage, koennte das mal einer in einer Grafik festhalten und hier darstellen?
Ich habe langsam das Gefuehl, dass hier einiges durcheinander geht. Also ich kann leider nicht folgen.
Warum sieht der DAC den BB?
Falls ich der einzige bin der hier nicht mehr mitkommt.... dann ignoriert mich einfach.
Finde das Thema grundsaetzlich spannend vote deshalb fuer mehr Nachvollziehbarkeit anhand einer/mehrerer Grafik, die ich leider nicht erstellen kann.

Gruesse und weiter so :-)

Thomas
Bild
gregor
Aktiver Hörer
Beiträge: 669
Registriert: 08.03.2010, 20:08

Beitrag von gregor »

Hallo PC-Hörer!

Eigentlich wollte ich ein wenig zur Aufklärung beitragen und Fujaks Erklärung suchen, weshalb er den BB doch braucht, doch ich find sie einfach nicht.
Vielleicht gelingt mir aber eine Vereinfachung zumindest EINER der Diskussionen hier:
Wenn ich Leif richtig verstanden habe, dann reicht Fujak die direkte USB-Verbindung über echtes ASIO zwischen Netbook und Fireface UC deswegen nicht, weil das Netbook nicht genug "Dampf" unter der Haube hat, richtig? Dass zusätzliche, hardwareseitige Optimierungen möglich wären mal beiseite.
Also, die vereinfachte These ist, echtes ASIO braucht echte Rechnerleistung (ohne unnötige Tasks), dann wirds gut, gibt man sich mit der Hardware noch mehr Mühe und passt das Betriebssystem an, wirds richtig gut.
Wenn ich Leif weiter verstehe, sieht der den Einsatz von Reclockern gar nicht grundsätzlich als falsch, sondern er sagt, es geht auch einfacher und vor allem billiger. Heißt für mich, wer die Investition für den BB in den richtigen DAC steckt hat insgesamt mehr davon?

Hab ich das jetzt richtig "heruntergebrochen"? Falls nicht, bitte nicht übel nehmen, es war nur ein Versuch.

Übrigens will ich noch warten, bis ich dem Thread mit den Stichworten MAC, CoreAudio, Hog-Mode am Fireface UC, 64 Bit Rechenmatrix und RAM-Play in Decibel.... weitere Komplexität angedeihen lassen könnte.

Beste Grüße

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

Beitrag von uli.brueggemann »

analog+ hat geschrieben:Hallo Uli,

Asio alleine ist ein Stück Software, ein Treiber, der ohne PC und Dac gar nichts macht.
Und er muß spezifisch an den jeweiligen Dac angepasst sein. Die erzielbare Qualität hängt ab von der Qualität des Dac und der Programmierung des Treibers.

Die Idee, Asio mit Reclocking zu verbinden klingt reizvoll, dürfte aber ohne weiteres kaum funktionieren:
Denn der Dac sieht in unserem Fall den BB und nicht mehr den PC auf den er direkt zugreifen müsste - der BB ist kein Dac.
Andernfalls: Wenn der BB Dac-Funktionalität erhielte, könnte er mit dem passenden Treiber den PC steuern.
Doch dann kann man doch dafür gleich den richtigen Dac nehmen, denn der kann das ohnehin. Er muß halt eine gute Clock haben.
Roland,
die Diskussion scheint mir auf mehreren Ebenen zu laufen. Dass Asio ein Stück Software ist, ist mir wohl bekannt. Da ich ja Programme schreibe, die Asio verwenden.
Demzufolge muss ich mich anscheinend unklar ausdrücken, sonst würdest Du mich nicht aufklären wollen.

Mmhh, also mal präzise:
Der Asio-Treiber sieht auf der PC-Seite festgelegte Ein-/Ausgabe-Puffer mit 32 bit single float precision, jeweils zwei Puffer je Ein-/Ausgabe. Die Grösse ist festlegbar und definiert eine Basislatenz.
Auf der Ausgangsseite/Eingangsseite sieht der Asio-Treiber keinen Dac, sondern die Soundkarte und die hierbei verwendete Hardware. Im gesamten Thread hier wird z.B. über spdif gesprochen, d.h. der Asio-Treiber bedient die Soundkarte eben so, dass sie per spdif ausgibt bzw. spdif-Daten einliest. Natürlich kann auch ein ADC- und DAC-Wandler im Spiel sein, muss aber nicht. Die Wandler können ja ausserhalb sitzen.
Ergo: der Asio-Treiber ist ein Stück Software, welches angepasst an die Hardware einer Soundkarte Daten zwischen PC und Aussenwelt handhabt.

Nun hat Leif ja die Meinung vertreten, dass Asio gegenüber anderen Windows-Treibern Vorteile bietet und im Zusammenhang mit cmP nachfolgende Reclocker hinter der spdif-Schnittstelle unnötig sind. Es sind klar Vorteile da, weil Asio keine internen Mischvorgänge und Abtastratenwandlungen vornimmt (wie etwa kmixer welches versucht, im Extremfall die 192kHz High-End-Musik mit einem 22 kHz Windows-Systemklang gleichzeitig auszugeben). Was aber nicht heisst, dass der Asio-Treiber z.B. definitv 24 bit PCM auf spdif ausgibt, was er könnte, was aber der Treiber-Programmierer vielleicht nicht vorgesehen hat. So dass dann z.B. 16 bit ungedithert rausgehen.

Fazit: da der Asio-Treiber nicht veröffentlicht ist, kann er super sein, muss es aber nicht. Demzufolge kann sich die Asio-Qualität auch von Soundkarte zu Soundkarte unterscheiden.

Darüber hinaus wird die Taktqualität der spdif-Ausgabe auch von anderen Dingen beeinflusst, wie eben die aktuelle Prozessorlast (x Programme und Dienste im Multitasking) bzw. die Belastung der Stromversorgung durch CPU, Festplattenklappern etc.

Der Ansatz seitens cmP² ist sicher richtig, nämlich genau all die negativen Einflüsse soweit wie möglich zu verringern, der Soundausgabe entsprechend Priorität zuzuweisen etc., also alles zu tun, damit der Datenfluss bis zu spdif möglichst ungestört läuft. Wenn man dann Glück hat, freut sich der angeschlossene DAC und dankt es einem mit einer guten Wiedergabe.

Fujaks Ansatz (und Erfahrung) ist, dass trotz allem ein nachfolgendes Reclocking Verbesserungen bringen kann (wir sollten mittlerweile gelernt haben, dass Asio alleine nicht 100% Qualität bedeutet). Ich teile dies aus meiner Sicht ebenfalls (minimales Echtzeit-Linux, geschätzt max. 20 Prozesse, die meisten schlafend, direkte Ankopplung Soundkarte per ALSA-Treiber auf unterster Ebene), wobei hier der BigBen vor dem Digitaleingang hängt und sich so die Soundkarte beim Durchreichen (und Filtern) auf den sauberen Signaltakt synchronisiert.

Zuletzt: natürlich braucht es kein Reclocking, sofern ein DAC seinerseits ein internes Reclocking durchzuführen vermag. Soweit ich mich erinnere hat Apogee z.B. anfangs das Reclocking des BigBen als Baugruppe angeboten, diese könnte auch in der Rosetta sitzen. Wer weiss.

Grüsse, Uli
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo zusammen,

solange in dieser Diskussion ASIO mit dem Thema Jitter in einen Zusammenhang gesetzt wird, wird diese Diskussion undurchschaubar. Das eine hat mit dem anderen nichts zu tun. ASIO ist ein Randthema bei der Betrachtung von Jitter reduzierter Wiedergabe (bitidentische Wiedergabe vorausgesetzt). Entscheidend für den Klang ist, wie sauber das Taktsignal den PC via SPDIF verlässt, bzw. bei USB wie sauber getaktet der PC das Versenden der Datenpakete steuert.

Durch cmp² kann das durch dessen Konfiguration bereits im Ansatz erheblich minimiert werden.

Wer dies nicht tut, kann das Signal zur weiteren Jitteroptimierung auf der Empfängerseite nachbehandeln:
a) Bei USB durch einen asynchron arbeitenden USB-Eingang im DAC, der den Eingang der Datenpakete mit seiner eigenen - hoffentlich präzisen Clock steuert (z.B. Ayre, Wavelength etc.)
b) mit SPDIF (egal ob aus dem PC direkt oder via Hiface) an einen DAC mit internem Reclocking-Baustein, und - wenn dieser nicht vorhanden - mit einem externen Reclocker wie dem Big Ben.

Es wäre für die weitere Diskussion außerordentlich hilfreich, die Erörterung über die ASIO-Schnittstelle nicht mit der Erörterung über die beste Clocking-Variante zu vermischen. Ansonsten sehe ich kaum Chancen, dass bei dieser Diskussion noch etwas sinnvolles herauskommt.

Grüße
Fujak
Bild
Antworten