Darf ich zu dem Punkt mal rückfragen bzw. mich wundern?Truesound hat geschrieben: Zwischen Samplitude und den anderen Playern die ich bislang dagegen hören konnte gibt es schon erhebliche Unterschiede wenn es beim Abhören gilt absolut sicher zu sein wie eine Aufnahme wirklich klingt. Das geht mit den anderen Playern nicht wirklich.
Grund: es ist prinzipiell eine einfache Angelegenheit, eine Playersoftware zu schreiben. Bevor Ihr auf mich draufhaut, werde ich das erläutern.
Ich geh davon aus, dass ich ASIO verwende, welches per defintionem nicht die MS-Kerneltreiber verwendet. Also nicht MMS, WASAPI, DIRECT SOUND etc. Der Soundkartenhersteller stellt den Treiber zur Verfügung (gilt auch für andere Lösungen ohne ASIO). Damit muss der geneigte Hörer leben, da ist man schlichtweg davon abhängig, dass der Fuzzi beim Soundkartenhersteller sein Handwerk versteht.
Die ASIO-Schnittstelle ist eindeutig definiert. Und zwar per Bufferswitch. Es gibt bei der Wiedergabe zwei Puffer mit der Größe 512, 1024 ... Samples. Zumeist lässt sich die Puffergröße im Interface wählen.
Nun kommt der Player ins Spiel: der holt sich irgendwoher Daten. Von der Festplatte, aus dem Ram-Speicher. Wie er das macht, obliegt dem eigenen Geschmack. Am Ende bekommt der Player schlichtweg ein Event oder Ereignis auf das er reagieren MUSS - der Bufferswitch. Hierbei wird zwischen den zwei Puffern gewechselt. Aus dem einen Puffer liest nun der ASIO-Treiber die Daten und gibt sie aus. In den anderen Puffer muss der Player derweil den nächsten Datenblock für die Ausgabe reinschreiben. Damit das schnell geht, passiert das üblicherweise über ein Move Block Kommando.
Der Player hat sonst nix mit der Ausgabe zu tun, das macht der Treiber. Demzufolge ist es egal, was für ein Player es ist. Er muss nur zeitgerecht den Bufferswitch bedienen. Ich geh mal davon aus, dass darauf seitens der Programmierung geachtet wird.
Folglich ist die Ausgabe allein davon abhängig, wie der Scheduler des Betriebssystems seine Prioritäten verteilt. So dass also der Bufferswitch möglichst direkt bedient wird. Und so, dass der Treiber selbst für die Zeiten, in denen er die CPU beansprucht (ein anderer Teil sollte wohl über DMA laufen), die CPU auch bekommt. Dazu erlaubt das Betriebssystem einige Maßnahmen: Änderung der Prozessprioritäten, Bevorzugung Hintergrunddienste, Abschalten unnötiger Prozesse = einfachere Entscheidungen beim Scheduler. An der Stelle kann die Playersoftware noch etwas beeinflussen.
Ansonsten ist da nix. Es ist völlig egal, ob die Musikdaten in einem zusammenhängenden oder fragmentierten Speicher zwischengepuffert werden. Wenn das Zusammensammeln fragmentierter Daten den Klang beeinflusst, dann hat der Treiber nicht genügend Priorität. Oder es entstehen unkontrollierte Effekte (Noise) auf irgendwelchen Busleitungen. Da kann der Programmierer des Players aber nur rätseln und nichts gezielt tun. Eine andere CPU, ein anderes Board und schon wäre auch die Wiedergabe anders.
Also zusammengefasst: zwei Puffer. Aus einem wird gelesen, in den anderen wird geschrieben. Die Soundkarte veranlasst eine Umschaltung über den Treiber.
Nun erklär mir mal einer sachlich, was nun dann die Klangänderungen bewirkt. Wir reden dabei ja immer von einer bitgetreuen Wiedergabe, die ihrerseits ja auch prüfbar ist. Ich hab das als selbstverständlich vorausgesetzt.
Grüsse
Uli
:
