Asio Bufferswitch Timing

Hallo Uli,

da bin ich absolut deiner Meinung - was die Quelle nicht hergibt …

Gruß
Hendrik

Moin zusammen,

es ging um diese Fragestellung von Bernd Peter:

Bernd Peter hat geschrieben: 23.12.2025, 18:49... wenn ich es richtig interpretiere, dürfte somit die Kombi Win 11 und Diretta rein technisch betrachtet keine highendige Lösung für den Host PC sein, oder?

Und da meine ich genügt es nicht, nur mit dem Test des Diretta ASIO Treibers eine Aussage dazu zu treffen. Denn die eigentliche Arbeit des Diretta Netzwerkprotokolls liegt ja hinter diesem Messpunkt. Der Diretta ASIO Treiber sieht den DAC noch nicht einmal, sondern dieser hat zwei Funktionen: den Datenstrom vom Host für das Diretta Netzwerk einzuspeisen und über zahlreiche Einstellungsmöglichkeiten diesen Datenstrom mit möglichst wenig Rauschen und Jitter an das Diretta Target zu senden.

Erst am Target kommt USB ins Spiel. Möglicherweise profitiert Robert von Diretta, weil das Netzwerkprotokoll am Host die Daten in kleine Pakete packt und der Datenpuffer am Target mit dem Host synchronisiert wird. So habe ich die grundsätzliche Funktionsweise verstanden. Nur sehen wir mit dem Programm AsioTimeTest gar nicht dieses Ergebnis. Das gebe ich zu bedenken.

Grundsätzlich bin ich aber schon der Meinung, dass bereits am Host ein gutes Timing wichtig ist. Hier halte ich jedoch das von Horst in's Spiel gebrachte Tool PC Clock Timing Test von David Taylor für aussagekräftiger. Denn in meinem Fall hat der AsioTimeTest ja recht positiv abgeschnitten. Nur hat das für NAA (Network Audio Adapter) keine Relevanz. Denn hier kommt USB am Host gar nicht vor.

Ich habe gestern Abend am Host mein Betriebssystem gewechselt und direkt mit dem HQPlayer OS die Musik gehört. Und das hört sich für mich besser an. Vielleicht liegt es an Windows 11, welches bei mir mit dem PC Clock Timing Test schlecht abschneidet. Windows würde ich für meinen Server gern weiter verwenden, um unter anderem Acourate für die Raumakustik nutzen zu können. Und hier habe ich jetzt eine Baustelle.

Grüße Gabriel

Hallo zusammen,

ich möchte als Einleitung nochmals auf das hinweisen was Microsoft geschrieben hat.

"Often QueryPerformanceFrequency doesn't return the actual frequency of the hardware tick generator. For example, in some older versions of Windows, QueryPerformanceFrequency returns the TSC frequency divided by 1024; and when running under a hypervisor that implements the hypervisor version 1.0 interface (or always in some newer versions of Windows), the performance counter frequency is fixed to 10 MHz. As a result, don't assume that QueryPerformanceFrequency will return a value derived from the hardware frequency".

Microsoft räumt also ein, dass es bei älteren Betriebssystemen bezüglich HPET / TSC anders ist als bei neueren (Windows 10, Windows 11 ?)

Ich wollte es dann mal genau wissen und habe eine Testreihe gefahren.
Verschiedene Betriebssysteme auf einem Rechner, bei identischen BIOS Einstellungen.
Es wurde die Performance Counter Frequenz in Abhängigkeit von der "useplatformclock" Konfiguration dargestellt.
Da die Ergebnisse so spannend waren, habe ich dann noch zwei weitere Rechner hinzugezogen.

Grundlage war die Feststellung dass auf meinem Audio-PC es klanglich nur dann hervorragend war, wenn "useplatformclock" auf "false" gesetzt wurde. Also deaktiviert.
Die "Performance Counter Frequenz" nahm dann einen Wert mit CPU-Frequenz / 1024 an und nur dann war es klanglich richtig gut.
Was ist wenn das bei anderen Betriebssystemen als meinem Server 2016 gar nicht möglich ist.

Hier mein Weihnachtsgeschenk an euch.
Wenn ihr euch die Tabelle anschaut, versteht ihr vielleicht, warum ich Server 2016 aus Audio Sicht seit gestern als das "the one and only Betriebssytem" betrachte.



Viele Grüße
Horst

ich kann nun verstehen warum Leute die Windows 10 nutzen, behaupten, dass es klanglich keinen Unterschied macht, ob sie HPET aktivieren oder nicht.
Sie können gar nicht in den Genuss kommen mit der Performance Counter Frequenz Einstellung zu hören die ich nutze.

Viele Grüße
Horst

Moin Horst,

unsere Beiträge haben sich überschnitten, aber in der richtigen Reihenfolge. Vielen Dank für deine Testreihe. Damit ist nun für mich klar, dass Windows 10/11 im wichtigen PC Clock Timing einfach nur schlecht ist. Und sogar Windows Server 2019, wer hätte das gedacht?

Zum Glück ist Windows Server 2016 weiter gut verfügbar.

Grüße Gabriel

Hallo Gabriel,

man sollte im Hinterkopf behalten, dass die Ergebnisse für ein Server 2016 ohne Updates gelten.
Man weiß nicht was Microsoft mittels Updates als funktionelle Anpassungen einfließen lässt ...
Also immer mal wieder auf die Performance Counter Frequenz schauen.

Viele Grüße
Horst

Ich bin mir nicht sicher ob die Query Performance Frequency mit 10 MHz (anscheinend üblich bei neueren Betriebsystemversionen von Windows) unbedingt schlechter sein muss als die Taktfrequenz des Rechners geteilt durch 1024.

Zuerst einmal sollte klar sein dass mit TSC / HPET / PM Timer die Zugriffszeiten unterschiedlich sind. Was sich auf das Timing auswirkt. (TSC: ~20-40 ns, HPET: ~700-1000 ns, ACPI PM Timer > 1 µs)
Demzufolge ist TSC die erste Wahl = useplatformclock no. Ok soweit. Das ist geklärt.

Des weiteren lässt sich feststellen, dass üblicherweise Referenztaktgeneratoren, Beispiel Mutec Ref10 oder Antelope Isochrone, gerne einen Takt von 10 MHz liefern. Möglicherweise gibt es hier einen Zusammenhang mit der 10 MHz TSC.
Es liegt aber auf der Hand dass es eine synthetische Frequenz ist, da sie nicht in einem einfachen Teilerverhältnis zur CPU-Frequenz steht. An dieser Stelle ist das Teilen mit der 2-er Potenz 2^10 = 1024 sicher eine einfachere technische Lösung.

Allerdings, ein wenig googeln sagt dazu:

Google KI hat geschrieben:The 10 MHz synthetic TSC frequency in newer Windows (especially virtualized or on specific hardware) is a fallback for the Time Stamp Counter (TSC), a fast CPU timer, when the actual hardware TSC isn't perfectly stable or invariant due to power saving, core frequency changes, or virtualization, providing a reliable, though slower, constant rate for apps needing precise timing without TSC issues, ensuring stability for timers like QueryPerformanceCounter (QPC) across different CPU states

Wir haben hier aber auch genau herausgefunden, dass es besser ist, die Leistung nicht zu begrenzen, eine feste Frequenz vorzugeben und Schlafzustände zu vermeiden. Wenn das nicht der Fall wäre, z.B. die CPU-Frequenz sich ständig ändert, würde auch der 1024-Teiler nicht helfen.

Man sollte übrigens auch im Hinterkopf behalten dass letztlich die Abtastraten der Audiowiedergabe auch nicht in einem einfachen Teilerverhältnis zur TSC-Frequenz stehen. Es darf munter weiter synthetisiert werden.

Grüsse
Uli

PS: das Ergebnis wird ja wiederum auch dadurch beeinflußt wieviele Prozesse und Threads sich die CPU teilen. Logischerweise gibt es dann die Fraktion, die die Reduzierung auf eine kleinstmögliche Anzahl bevorzugt. An dieser Stelle möchte ich aber noch ein neues Fass aufmachen. Gerade bei den neueren Mehrkern-Prozessoren kann man ja auch versuchen bestimmte Prozesse/Threads nur auf bestimmten Kernen laufen zu lassen. So dass sie unbeeinflußt von anderen Prozessen/Threads z.B. des Betriebssystems sind. Aber halt: das Faß kann noch größer sein. Man teilt sich damit immer noch gemeinsame Ressourcen wie den Arbeitsspeicher. Bisher hat hier noch keiner das Thema NUMA (https://en.wikipedia.org/wiki/Non-uniform_memory_access) angesprochen. Es sollte möglich sein (so Mainboard und CPU es hergeben), dass Audio-Prozesse (inkl. Asio, Datenübertragung etc.) damit dediziert auf bestimmten Kernen mit einem dafür eigens reservierten Arbeitsspeicher laufen.
So viel Zeit und nix zu tun

PPS: ich wünsche allen ein Frohes und lauschiges Weihnachtsfest! Mein Wunsch möchte Euch alle zeitgenau erreichen, ich hoffe es gelingt !

Hallo zusammen,

StreamFidelity hat geschrieben: 22.12.2025, 18:43 Windows 11 wird ja immer schlimmer mit Lauschangriffen wie Telemetrie-Daten an Microsoft und nun wird der Copilot (KI) immer stärker eingebunden.

Zustimmung! Ich bin deshalb aus Neugierde zurück auf Server 2012 (RamBoot), habe das hier erworbene Know-How darauf angewendet und -voila - unten die Ergebnisse.

Frohe Weihnachten,
Heinz

Hallo Heinz,

das schaut ja richtig toll aus.
Ist das 2012 R2 oder 2012 ?
Könnte ich vielleicht auch mal wieder ausprobieren, jetzt zusammen mit all dem anderen was wir die Jahre gelernt haben.
Laut meiner Tabelle läuft auch bei Server 2012 der PCF mit CPU-Takt / 1024
Also geeignet !

Was steht bei dir als PCF drin in der Tabelle von David Taylor?


Viele Grüße
Horst

Das sind sehr gute 0,01 ms Zeitvariation



Viele Grüße
Horst

Hallo Horst,

Trinnov hat geschrieben: 24.12.2025, 11:01 Ist das 2012 R2 oder 2012 ?
Könnte ich vielleicht auch mal wieder ausprobieren, jetzt zusammen mit all dem anderen was wir die Jahre gelernt haben.
Laut meiner Liste läuft auch bei Server 2012 der PCF mit CPU-Takt / 1024
Also geeignet !

Was steht bei dir als PCF drin in der Tabelle von David Taylor?

Das ist der Server 2012 R2, mit dem wir damals im RAM angefangen haben. Normale Größe, nicht geshrinkt. Alles weitere unten.

Oldies but Goodies!
Heinz

Hallo Heinz,

das schaut eigentlich genauso aus wie meine PC Clock Frequencies Tabelle.
Hast du zufällig das gleiche Mainboard, gleiche CPU und gleichen Multiplikator ?
Aber bitte Detail Info nur per PM.
Nur deine Standard Deviation ist noch niedriger bei 0,0 µs

Viele Grüße
Horst

Auch ganz interessant.
Das sind die Werte, die man bekommt, wenn man die Average Bufferswitch Time von der Nominal Bufferswitch Time abzieht.
Oder umgekehrt. Je nachdem was größer ist.
Mein Glückwunsch geht an Uli !

Es darf diskutiert werden, ob es das klangliche Ergebnis wiederspiegelt.





Viele Grüße
Horst

Meiner Meinung nach ist die Methode eine Differenz zu bilden nicht geeignet um daraus eine klangliche Einstufung zu ermöglichen.

Es gibt Plots, die eigentlich sehr schlecht sind, also viel Zeitvariation und es ergibt sich trotzdem einen Average Wert nahe des nominalen Werts. Somit kann man mit dem Ergebnis der Differenzbildung nichts anfangen.
Außer Uli denkt nochmal über die Berechnung nach.

Top Differenzwert, aber schaut gruselig aus. Ist auch von Uli.
0,000058




Sehr wenig Zeitvariation, trotzdem schlechter Differenzwert
0,001376





Nochmal Uli. Schlaut schlimm aus aber guter Differenzwert.
0,000122





0,009248



Viele Grüße
Horst

Hallo Horst,

AsioTimeTest ist ursprünglich entstanden weil mich schlichtweg interessiert hatte, wie sich unterschiedliche Asiotreiber verhalten. Dass sich dann dabei mit herausgestellt hat, dass man auch prima Rückschlüsse auf das Zeitverhalten des Rechners mit all seinen Prozessen ziehen kann, war erst einmal nicht beabsichtigt.
Wie immer muss man aber aufpassen was denn da so passiert und wie man etwas interpretiert.

1.
wenn z.B. der Asiopuffer 512 Bytes groß ist und die Abtastrate 48 kHz beträgt (1024 Bytes + 96 kHz wären da gleichwertig) so ist die Bufferswitchtime 512/48000 = 0,0106666666666 s. Wenn der Timer 100 ns Auflösung hat (z.B. TSC) dann kann man damit Zeiten erfassen mit 0.0106666 s oder 0.0106667 s. Eine gemessene Zeit müsste dazwischen hin- und herschwanken, weitere Nachkommastellen wären eher zufällige Werte.
Würde man nun aber wie beim AsioTimeTest 4096 Switches erfassen, so müsste die gemessene Zeit sich ausmitteln mit eben Summe der 4096 Messungen durch 4096.

2.
das theoretische Ideal wäre ja beim AsioTimeTest eine gerade Kurve mit allen Punkten auf 10.666666666 ms (unser Beispiel). Nach 1. wäre eine Zickzackkurve zwischen 10.6666 ms und 10.6667 ms zu erwarten.
Ich habe dazu mal den Hapi (Ethernet Ravenna-Protokoll) gemessen und bekomme (so denn gerade keine anderen Prozesse dazwischenfunken) dann folgendes (gezoomt):



Ich glaube besser wird es nicht gehen und das bei Win11 mit derzeit um die 165 Prozesse (aber bitte im Hinterkopf behalten: es gibt leider auch hier in der Realität Abweichungen die größer sind. Es passt aber gerade prima zur Veranschaulichung, die Messung ist real).

3.
Wir haben ja keinerlei Einfluß darauf, wie ein Soundkartenhersteller seinen Treiber schreibt. Und so stellen sich dann Charakteristika heraus welche quasi einen Fingerabdruck des Treibers darstellen. Beim RME Fireface UC zeigt sich z.B. folgendes:



Da gibt es Zeiten mit 10.75 ms anstelle der 10.6667 ms. Um das auszugleichen gibt es anschliessend zwei gleich große Zeiten welche niedriger sein müssen. Also = (3* 512/48000 - 0.01075) / 2 = 0.010625 = 10.625 ms
Was dann hier auch der Fall ist. Vielleicht hat sich RME gedacht,dass drei Bufferswitches eine Zeit ergeben welche sich wiederum mit der 100 ns-Auflösung darstellen lässt. Was bei 44100 wiederum nicht aufgeht, ich muss mir das nochmal anschauen.

4.
Ein Extremfall zeigt sich bei einer Focusrite USB-Soundkarte.



Hier liegt die Bufferswitch-Zeit bei ca. 10.98 ms. Das wird nun 31-mal so durchgehalten. Damit das aber nicht aus dem Ruder läuft, wird dann bei Switch 32 die Zeit extrem kurz. Also in etwa (32*512/48000 - 31*0.01098) = ca. 1 ms
Da hätte dann evtl. die Wiedergabe Probleme wenn der Player den Buffer nicht in dieser Millisekunde füllen kann.
Übrigens war dieses bei Focusrite beobachtete Verhalten der Anlass dafür, dass ich beim AsioTimeTest den Durchschnittswert ermitteln lasse.

5.
Wir haben gesehen, dass bei dieser Betrachtung Störzeiten aufgrund eines Umschaltens auf andere Prozesse/Threads durch den Scheduler noch ganz aussen vor sind. Genau genommen kann ja ein Asiotreiber auch intern die Zeiten durch Auslesen des Performance Counters messen, diese aufsummieren und dann durch passende Aufrufe eines Bufferswitches so gegensteuern, dass im Durchschnitt die Zeiten passen und nicht weglaufen. Wie bereits gesagt, hat darauf der Programmierer des Abspielprogramms selbst keinerlei Einflußmöglichkeiten mehr. Da ist dann die Frage, wie clever der Asiotreiber geschrieben wurde.

6.
Der Vergleich der durch AsioTimeTest ermittelten Durchschnittszeit als Differenz zur Nominalzeit hängt nun aber auch davon ab, wie gut dann eine Strategie beim Asiotreiber mit den quasi willkürlich gewählten 4096 Switches zusammenpasst. Ein Beispiel: wäre die Messung 31 Switches lang, würde bei Focusrite der Durchschnitt 10.98 ms oder 10.658 ms sein (je nachdem ob der kurze Switch in der Messung dabei ist. Die Differenz wäre dann 0.313 ms oder 0.0087 ms.
Bei zusätzlichen Zeitschwankungen durch Prozesstörungen wird das also ingesamt sehr unzuverlässig. Und selbst ein Differenzwert von 0 heisst nichts, ausser dass die Zeit über 4096 Switches insgesamt nicht grob wegläuft.

Viele Grüsse
Uli

PS: ach ja, ob sich da nun eine klangliche Signatur entsprechend dem Fingerabdruck des Asiotreibers ergibt (welcher ja der Absicht des Anwenders mit seinem Bemühungen um Windows/Linux, Server/WinXX, Windows im RAM entgegenwirken kann), muss eben jeder für sich selbst feststellen. Eine absolute Vergleichsaussage kann da problematisch sein.