unter Windows benötigen DACs und Soundkarten ja ihre Gerätetreiber, die im allgemeinen vom jeweiligen Hersteller mitgeliefert werden. Die Treiber sind in diesem Sinn proprietär. Was also drin steckt weiss der Anwender üblicherweise nicht. Um Unzulänglichkeiten bei Windows Sound zu umgehen wurde von Steinberg die Asio-Schnittstelle definiert, die Treiber gehen am Windows-Mixer bzw. sogar am Kernel (Hörensagen) vorbei. Insofern sind heute die Asio-Treiber i.a. beliebt und werden gern bevorzugt.
Unter Linux gibt es ALSA, da kann also ein Sachkundiger in die Quelltexte reinschauen. Allerdings sind es dann eher generische Treiber, die für die Soundkarten gelten, sie sind nicht notwendigerweise vom Hersteller optimiert.
Bleiben wir bei Windows. Linux wird hier ja bereits von anderen intensiv diskutiert, siehe Frankl's Arbeiten etc.
Wir kennen ja bei Windows nun zahlreiche Versuche die Wiedergabe zu verbessern. Reduzierung von Prozessen und Diensten, Tools wie Fidelizer und AO, Optimierung von Stromversorgung und Quarzen und vieles andere mehr.
Die Asio-Geschichte ist dabei immer ein Buch mit 7 Siegeln. Die jeweils verwendeten Treiber sind dlls, also dynamic linked Libraries, was nichts anderes ist als Programme, die dann in die Playerprogramme mit eingebunden werden. Die Kommunikationsschnittstelle ist definiert, nicht jedoch die Reihenfolge der jeweiligen Kommandos. Trotzdem funktioniert das i.a. ganz gut.
Nun, die Treiber als Programme bzw. dlls werden von Programmierern bei den Herstellern erstellt, teilweise auch bei der Fa. Thesycon als Dienstleister. Es muss demzufolge laufen. Aber wer sagt dass sie damit audiophilen Gesichtspunkten genügen?
Die Timing-Diskussion von Frank bei Linux hat mich dazu bewegt mal nachzuschauen was da bei Asio zu erkennen ist. Nun muss man wissen, dass Asio mit einem Wechselpufferprinzip arbeitet. Während der Player in einen Puffer Daten schreibt liest der Treiber den anderen Puffer und gibt die Daten an die jeweilige Hardware weiter (z.B. über USB, Ethernet, I2S ...). Der Player muss nur schnell genug schreiben, dann kann der Puffer umgeschaltet werden wenn die dll neue Daten benötigt. Und so fliesst es dann kontinuierlich, zumindest theoretisch.
Das Umschalten besorgt die dll, sie ruft eine Callback-Prozedur auf und der Player führt diese dann aus mit seiner Pufferbearbeitung.
Wenn also z.B. ein Asio-Puffer von 512 Byte bei 44100 Hz verwendet wird, muss demzufolge alle 512/44.1 = ca. 11.6 Millisekungen ein Pufferwechsel stattfinden. Das Timing gibt die dll vor.
Und wie genau ist nun das Timing?
Ich habe dazu ein Programm geschrieben was eigentlich nichts tut. Es startet das Asio und wartet auf den Bufferswitch durch den Asiotreiber. Just in dem Moment wird als erstes der aktuelle Wert des unter Windows vorhandenen High Performance Timers (HPT) ausgelesen. Die Frequenz des HPT ist heute i.a. 10 MHz und unabhängig von der CPU-Geschwindigkeit. Die Differenz der Zeit zur vorherigen Zeit ergibt dann die momentan gültige Bufferswitchzeit. Idealerweise wäre sie konstant. Wenn nicht das Betriebssystem als Multitasking-System dazwischenfunken täte. Windows ist kein Echtzeitbetriebssystem (Linux bzw. MAC i.a. auch nicht). Und so ist es spannend was dabei herauskommt.
Einige Beispiele gezoomt, man beachte die unterschiedliche Skalierung in y:
Firface UC
Focusrite 6i6
Asio4All mit Realtek-Chip
Beim Focusrite-Treiber ist spannend, dass da im Prinzip immer 31 Switches mit 12 ms zu lang sind und dann ein ganz fixer Bufferswitch mit nahezu Null den Timing-Durchschnitt von 11.6 ms sicherstellen muss.
Meine bescheidene Annahme: wenn sich schon diverse Treiber so unterscheiden und wenn dabei das Betriebssystem entsprechend dazwischenfunkt
was hülft es wenn man da am System herumtweakt? Wohlgemerkt, die Musik hat beim Abspielen mit obigen Beispielen zumindest keine hörbaren Aussetzer. Oder pflanzen sich Abweichungen im Timing trotzdem fort bis in die gehörte Wiedergabe?
Nichtsdestotrotz ist es ja vielleicht doch interessant im Rahmen der Community eine gemeinsame Untersuchung vorzunehmen. Fragen sind z.B.:
- wie verhalten sich identische Soundkarten/DACs auf unterschiedlichen Rechnern
- kann man dann bei einen optimierten System ein verbessertes Verhalten feststellen
- gibt es einen Treiber der optimale Kurven liefert und wie klingt es
- welcher Treiber sieht am schlimmsten aus und wie klingt es?
- wie schaut es bei Euch aus?
Das Programm AsioTimeTest gibt es hier als Setupdatei oder als portable 7zip-Version
Die Ergebnisse werden im Chart angezeigt (Doppelklick darauf z.B. für Export etc.) bzw. als dbl-Datei (z.B. für Acourate) im Verzeichnis \Dokumente\AsioTimeTest gespeichert. Der Dateinamen ist hier z.B. AT-Fireface UC-44-512-0-2-15.dbl (= Fireface UC, 44.1 kHz, Puffer 512 Byte, 0 Eingänge, 2 Ausgänge, Asio-Thread-Priorität 15 oberhalb Programmpriorität)
Viel Spass damit. Ich bin gespannt auf Eure Ergebnisse, insbesonders darauf wie sich optimierte Systeme verhalten. Für eine Vergleichbarkeit wäre es evtl. prima wenn man Messungen mit 44.1 kHz und einem 512 Byte Buffer durchführt. Bei einer Soundkarte mit z.B. 32 Ein-/Ausgängen wäre aber auch ein Extremtest denkbar mit einen 64 Byte Puffer und 384 kHz Abtastrate (was der Treiber eben hergibt) und das dann noch zusammen mit einem Stresstest-Programm, z.B. HeavyLoad o.ä.
Optimal wäre es definitiv wenn man konkrete Lösungen aufzeigen und nachweisen kann, die das Verhalten gegebener Asiotreiber verbessern.
Viele Grüsse
Uli
Demzufolge wäre ja die Schlussfolgerung, dass man genauer wird wenn die CPU arbeitet. Wieso reduzieren dann alle immer die Anzahl der Prozesse und Dienste?
