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