Alle drei Punkte kann ich eindeutig zustimmen, nur die Frage welcher Weg der bessere ist.
Ich möchte aber nochmals betonen dass meine Position zu diesem Thema kein Proteststurm gegen BigBen ist. Dass er so überzeugend klingt ist schlicht ein Indiz dafür dass es ohne BigBen deutlichen Jitter gibt und dass dies mich in veranlasst auf ASIO aufmerksam zu machen.
Wo man ohne ASIO auskommen muss, ist re-clocking natürlich der einzige Weg.
Z.B ist die unabhängige Clock-synchronisierung nicht machbar wenn irgendwo in der Kette diese unterbrochen wird., sei es nun weil das Signal durch ein S/PDIF Kabel muss oder weil ein Element der Kette diese asynchrone Verbindung nicht verwenden kann.
Damit hat sich ASIO für viele Anwender hier einfach erledigt.
Dennoch, wenn man wie du einen Computer und einen DAC hat, die prinzipiell mit ASIO so eine asynchrone Verbindung herstellen kann, sollte man es so tun. Das dein Netbook keinen FireWire Anschluss hat ist natürlich bedauerlich, und dass er die Prozessorleistung für die RME USB-ASIO Software auch nicht hat, ist doppelt ärgerlich.
Für die anderen die mitlesen : RME hat für den FireFace UC einen echten ASIO Treiber für die USB Schnittstelle entwickelt (BRAVO). Dazu aber auch dieses Statement abgegeben :
USB 2.0 ist auf Wintel-Rechnern schon seit circa 2002 zu finden, hat aber in den ersten Generationen des USB Controllers nicht so funktioniert wie es für Echtzeitaudio notwendig wäre. Auch wenn Rechner aus dem Jahre 2003 (z.B. Intel 875 mit P4 Prozessor) prinzipiell mit dem Fireface UC funktionieren, verursacht schon eine simple Stereo-Wiedergabe eine CPU-Last von 30%. Latenzen unter 256 Samples sind selbst in einer Minimalanwendung nicht immer knacksfrei. Bei genauerer Untersuchung stellt sich heraus, dass die CPU-Last im Grunde eine versteckte DPC-Last ist. Offensichtlich arbeitet der Interfacechip ineffizient, und zwingt dem Rechner (der CPU) Wartepausen auf.
Dieses Verhalten ist Treiber- und Betriebssystem-unabhängig. Erst mit dem ICH7 scheint Intel das Problem erkannt zu haben. Moderne Rechner mit ICH8, 9 und 10 weisen prinzipiell eine hervorragende USB-Performance auf, kommen dann aber auch meist mit einem Core 2 Duo Prozessor daher, so dass zusätzlich auch eine hohe Rechenleistung zur Verfügung steht. Aktuelle Netbooks sind oft mit ICH7 bestückt, daher prinzipiell kompatibel. Der schmalbrüstige Atom-Prozessor führt dann doch wieder zu einer recht hohen Belastung bei simpler Wiedergabe, was aber teilweise auch auf die integrierte Soundkarte zutrifft. Ältere AMD- und ATI-basierte Rechner besitzen oft katastrophale USB-Interfaces, die sich in der Praxis als vollständig inkompatibel zum Fireface UC erweisen.
Auf Basis der obigen Erkenntnisse, und um Enttäuschungen auf Seiten unserer Kunden zu vermeiden, wurden die Systemvoraussetzungen zum Betrieb des Fireface UC streng auf mindestens Core 2 Duo CPU festgelegt. Diese kommt immer zusammen mit neueren USB-Controllern. Ältere Rechner funktionieren durchaus, siehe Liste, aber eben mit Einschänkungen. Ob diese im Einzelfall akzeptabel sind kann nur der Kunde selbst entscheiden.
Ich würde dazu raten, entweder einen leistungsstärkeren und/oder FireWire fähigen Computer an dein Setup anzuschliesen und echtes ASIO zu probieren.
Dann kann der RME zeigen wozu er in der Lage ist.
Dann könnte es auch eine Revision zu cMP2 geben.....
Interssant wäre es auch die Clocksteuerung vom BigBen an den RME via BNC....(so wie ich Uli vorgeschlagen habe)
Hope to help !
Leif
) gesteuerte Datenabholung per geeignetem USB Protokoll überhaupt erst ermöglicht. Durch die Protokollsteuerung ab DAC kommt mir das USB Verfahren schon inhärent weniger jitteranfällig als SPDIF vor.
