USB in adaptive mode: A control circuit (sample rate guesser) measures the average rate of the data coming over the bus and adjusts the clock to match that. Pretty much like SPDIF.
USB in asynchronous mode: In this mode an external clock (in the DAC) is used to clock the data out of the buffer and a feedback stream is setup to tell the host how fast to send the data. A control circuit monitors the status of the buffer and tells the host to speed up if the buffer is getting too empty or slow down if it’s getting too full.
Since the readout clock is not dependent on anything going on with the bus, it can be fed directly from a low jitter oscillator. This is a bit like a DAC and a separate transport with a word clock from the DAC timing the transport. Bit more detail: http://thewelltemperedcomputer.com/KB/USB.html
Regardless of the OS (Win, OSX, Linux) we talk multi-tasking. As a consequence arrival of the data on time is never guaranteed (you need a real time OS to do so). Therefore all data is buffered. You can’t introduce jitter directly by using software. E.g. a program deliberately sending sample with small variations in timing (jitter) won’t work because all samples are received at the sound card and buffered.
If latency is low you can use a small buffer but a buffer is a buffer anyway. No real time streaming inside a multi-tasking environment by design.
Drivers like WASAPI, ASIO etc. don’t affect jitter, they do allow for a transparent path between audio software and sound card driver.
Software running generates electrical activity like CPU cycles, access to HD, etc. There can be a relationship between electrical activity and sound quality. Say the movements of the head of the HD induces a ripple on the power rail. This ripple affects the clock driving the sound card.
A measurement like this http://thewelltemperedcomputer.com/Intr ... ayback.htm demonstrates the difference in jitter level between a stopped and a running system. If this affects sound quality one must conclude that as sound quality fluctuates with system load, the sound card is not up to its job.
ASIO und Clocking
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4665
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Es werden immer wieder die Vorteile von ASIO zitiert. Das mag im Vergleich zu kmixer und Co. stimmen.
ABER:
Wir haben alle keinen Einblick, was im ASIO-Treiber genau passiert. Der ist spezifisch für jede Soundkarte und abhängig vom Können des Programmierers beim Hersteller. (Ich hab zumindest schon festgestellt, dass es verschiedene Updates für eine Soundkarte gegeben hat, warum wohl?)
Die ASIO-Schnittstelle sieht für das Einlesen und die Ausgabe jeweils zwei Puffer vor (von deren Größe die Latenz abhängt). Wähend die Soundkarte in einen Eingangspuffer schreibt, liest der PC (besser das Aufnahmeprogramm) den anderen Puffer aus. Und während der PC (besser das Play-Programm) in den Ausgabepuffer schreibt, liest der Treiber den anderen Puffer aus und übergibt die Daten an die Soundkarte. Bei Erreichen eines Puffer-Endes löst der Treiber beim Anwenderprogramm einen Bufferswitch aus, die Puffer werden dann gewechselt.
Nun ist so ein Puffer ja nicht im Nirvana, sondern schlichtweg im Speicher. Es finden also Speicherzugriffe statt. Auch wenn dann ein Zugriff im direct memory access stattfindet, muss man im Hinterkopf halten, dass alle Speicherzugriffe nun einmal im Wettbewerb stehen. D.h. dass alle mögliche Tasks auf den vorhandenen Speicher zugreifen. Daraus ergibt sich ein beliebiges Timing. Da hilft auch kein Realtime-System an sich, weil es ja neben der simplen Soundkarte noch Tasks mit höherer Priorität geben mag. Zumindest wird ein Scheduler laufen, der wiederum regelt, welcher Prozess nun dran ist. Und der darf immer dazwischenfunken. Und dann könnte ja auch noch ein Graphikchip ebenfalls im shared memory rumspuken, zumindest vom Speicherzugriff her.
Gar nicht zu sprechen von dem was so alles auf Seite der Spannungsversorgung passieren mag.
Ergo: ASIO alleine heisst nichts. Klar ist: wenn weniger Prozesse laufen, gibt es weniger Störungen. Das scheint mir der rudimentäte cmP-Ansatz zu sein.
Ideal wäre das Zugreifen in einen I/O-Puffer mit Tri-State-Logik (a la ASIO mit Bufferswitches), wo nach dem Füllen eines Puffers die Soundkarte einen alleinigen Zugriff hat und mit eigenem Takt ausliest. Der Puffer muss dann auf der Soundkarte sein. Während des Auslesens ist der PC-Bus hochohmig abgekoppelt und der Soundchip hat alle Rechte und keine weiteren Prozesse stören seine Arbeit. Wenn dann noch die Spannungsversorgung sauber ist ...
Tja, irgendwie träum ich vielleicht.
Grüsse, Uli
ABER:
Wir haben alle keinen Einblick, was im ASIO-Treiber genau passiert. Der ist spezifisch für jede Soundkarte und abhängig vom Können des Programmierers beim Hersteller. (Ich hab zumindest schon festgestellt, dass es verschiedene Updates für eine Soundkarte gegeben hat, warum wohl?)
Die ASIO-Schnittstelle sieht für das Einlesen und die Ausgabe jeweils zwei Puffer vor (von deren Größe die Latenz abhängt). Wähend die Soundkarte in einen Eingangspuffer schreibt, liest der PC (besser das Aufnahmeprogramm) den anderen Puffer aus. Und während der PC (besser das Play-Programm) in den Ausgabepuffer schreibt, liest der Treiber den anderen Puffer aus und übergibt die Daten an die Soundkarte. Bei Erreichen eines Puffer-Endes löst der Treiber beim Anwenderprogramm einen Bufferswitch aus, die Puffer werden dann gewechselt.
Nun ist so ein Puffer ja nicht im Nirvana, sondern schlichtweg im Speicher. Es finden also Speicherzugriffe statt. Auch wenn dann ein Zugriff im direct memory access stattfindet, muss man im Hinterkopf halten, dass alle Speicherzugriffe nun einmal im Wettbewerb stehen. D.h. dass alle mögliche Tasks auf den vorhandenen Speicher zugreifen. Daraus ergibt sich ein beliebiges Timing. Da hilft auch kein Realtime-System an sich, weil es ja neben der simplen Soundkarte noch Tasks mit höherer Priorität geben mag. Zumindest wird ein Scheduler laufen, der wiederum regelt, welcher Prozess nun dran ist. Und der darf immer dazwischenfunken. Und dann könnte ja auch noch ein Graphikchip ebenfalls im shared memory rumspuken, zumindest vom Speicherzugriff her.
Gar nicht zu sprechen von dem was so alles auf Seite der Spannungsversorgung passieren mag.
Ergo: ASIO alleine heisst nichts. Klar ist: wenn weniger Prozesse laufen, gibt es weniger Störungen. Das scheint mir der rudimentäte cmP-Ansatz zu sein.
Ideal wäre das Zugreifen in einen I/O-Puffer mit Tri-State-Logik (a la ASIO mit Bufferswitches), wo nach dem Füllen eines Puffers die Soundkarte einen alleinigen Zugriff hat und mit eigenem Takt ausliest. Der Puffer muss dann auf der Soundkarte sein. Während des Auslesens ist der PC-Bus hochohmig abgekoppelt und der Soundchip hat alle Rechte und keine weiteren Prozesse stören seine Arbeit. Wenn dann noch die Spannungsversorgung sauber ist ...
Tja, irgendwie träum ich vielleicht.
Grüsse, Uli
-
wgh52
- Aktiver Hörer
- Beiträge: 5651
- Registriert: 25.01.2008, 15:17
- Wohnort: Schweitenkirchen
- Kontaktdaten:
Freunde,
nach meinem rudimentären Verständnis ist diese Äusserung von Vincent wichtig:
Also: Ich würde diese "quasi-jitterfreie Übertragung" verstehen, wenn die USB Übertragunng an sich in einem Modus stattfindet, der um einiges schneller und sicherer als SPDIF ist und nicht jedes Bit synchronisieren muss, weil "genug Zeit ist" die übertragenen Daten ganz in Ruhe und vom DAC selbst super getaktet in den DAC zu holen und dort zu wandeln, vielleicht sogar bei Fehlern Übertragungswiederholungen ermöglicht....
Wie gesagt, ich verstehe zu wenig von diesen ganzen Sachen und würde gerne lernen.
Gruß,
Winfried
1691
nach meinem rudimentären Verständnis ist diese Äusserung von Vincent wichtig:
Dieser Satz gibt mir zu denken: Wie soll eine SOFTWARE Jitter im zig-Picoskundenbereich verhindern???? Da müssen andere Mechanismen dahinterstecken, die z.B. durch die "Softwareentkoppelung" Übertragungsmodi ermöglichen, die die immernoch serielle Übertragung "jitterunanfällig(er)" machen!Drivers like WASAPI, ASIO etc. don’t affect jitter, they do allow for a transparent path between audio software and sound card driver.
Also: Ich würde diese "quasi-jitterfreie Übertragung" verstehen, wenn die USB Übertragunng an sich in einem Modus stattfindet, der um einiges schneller und sicherer als SPDIF ist und nicht jedes Bit synchronisieren muss, weil "genug Zeit ist" die übertragenen Daten ganz in Ruhe und vom DAC selbst super getaktet in den DAC zu holen und dort zu wandeln, vielleicht sogar bei Fehlern Übertragungswiederholungen ermöglicht....
Wie gesagt, ich verstehe zu wenig von diesen ganzen Sachen und würde gerne lernen.
Gruß,
Winfried
1691
Hi Vincent,
ich antworte jetzt mal auf deutsch - das kann ich zweifellos besser...:
Exakt so ist es.
Asio ist ein Treiber, der entfernt natürlich keinen Jitter. Das müssen schon die Geräte tun, die mit ihm arbeiten. Und selbstverständlich gibt es Unterschiede in der Programmierung dieser Software!
Ansonsten ist das von Dir beschriebene Szenario genau die Stelle, an der das cmp-Projekt ansetzt:
Nämlich die Entstehung von Jitter im PC zu minimieren indem die daran beteiligten Komponenten unter Bedingungen betrieben werden, die die Reduzierung von "electrical noise" zur Folge haben; so z.B. Prozessorlast, Platten- und Ramzugriffe, Timing des Ram usw. Auch die Reduktion des Systems auf wenig Software und wenig Prozesse spielt hier eine erhebliche Rolle.
Dazu mal als Beispiel:
Ein Indikator für die Systemlast (Unruhe im System) ist die Latenz des Gesamtsystems. Normalerweise schwankt die stark und erreicht Spitzenwerte von 1000 ms und mehr. Ein cmp-System erreicht konstant (!) 1-2ms. Die Systemlatenz kann man sich mit Hilfe des Programmes "Latency check" auf seinem Rechner anzeigen lassen.
Außerdem ist durch diese niedrige Systemlatenz die Einstellung niedriger Audio-Puffergrößen möglich.
Nun ist es so, daß jeder Speicherzugriff Störungen induziert. Kleine Puffergrößen steigern die Häufigkeit der Speicherzugriffe, die Frequenz der Störungen steigt. Bei 32 Samples und 96 KHZ beträgt diese ca.3 khz. Mit dieser Störungsfrequenz kann eine PLL im Dac häufig besser umgehen, als mit einer von 1 khz oder darunter.
Und nochmal:
Je weniger Jitter ein Rechner produziert, desto leichter hat es der nachfolgende Dac damit umzugehen.
Nach meinen Erfahrungen kann man dann auf ein weiteres Clocking verzichten.
Hallo modmix,
Leif setzt im Rechner keine zusätzliche Karte ein, die Aurora hängt über Firewire direkt am PC.
Viele Grüße
Roland
ich antworte jetzt mal auf deutsch - das kann ich zweifellos besser...:
Exakt so ist es.
Asio ist ein Treiber, der entfernt natürlich keinen Jitter. Das müssen schon die Geräte tun, die mit ihm arbeiten. Und selbstverständlich gibt es Unterschiede in der Programmierung dieser Software!
Ansonsten ist das von Dir beschriebene Szenario genau die Stelle, an der das cmp-Projekt ansetzt:
Nämlich die Entstehung von Jitter im PC zu minimieren indem die daran beteiligten Komponenten unter Bedingungen betrieben werden, die die Reduzierung von "electrical noise" zur Folge haben; so z.B. Prozessorlast, Platten- und Ramzugriffe, Timing des Ram usw. Auch die Reduktion des Systems auf wenig Software und wenig Prozesse spielt hier eine erhebliche Rolle.
Dazu mal als Beispiel:
Ein Indikator für die Systemlast (Unruhe im System) ist die Latenz des Gesamtsystems. Normalerweise schwankt die stark und erreicht Spitzenwerte von 1000 ms und mehr. Ein cmp-System erreicht konstant (!) 1-2ms. Die Systemlatenz kann man sich mit Hilfe des Programmes "Latency check" auf seinem Rechner anzeigen lassen.
Außerdem ist durch diese niedrige Systemlatenz die Einstellung niedriger Audio-Puffergrößen möglich.
Nun ist es so, daß jeder Speicherzugriff Störungen induziert. Kleine Puffergrößen steigern die Häufigkeit der Speicherzugriffe, die Frequenz der Störungen steigt. Bei 32 Samples und 96 KHZ beträgt diese ca.3 khz. Mit dieser Störungsfrequenz kann eine PLL im Dac häufig besser umgehen, als mit einer von 1 khz oder darunter.
Und nochmal:
Je weniger Jitter ein Rechner produziert, desto leichter hat es der nachfolgende Dac damit umzugehen.
Nach meinen Erfahrungen kann man dann auf ein weiteres Clocking verzichten.
Hallo modmix,
Leif setzt im Rechner keine zusätzliche Karte ein, die Aurora hängt über Firewire direkt am PC.
Viele Grüße
Roland
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
Und nochwas zu Linux:
Das wäre natürlich sehr gut für Audio geeignet. Man kann es konfigurieren nach Maß, schlank und rank, und kostenlos ist es auch...
Aber leider gibt es dafür zu wenig Treiber. Die müsste man sich fast alle selber schreiben - und Asiotreiber sind, wenn man es avanciert angeht, keineswegs trivial. Wir hätten für viele unserer Lieblingsgeräte also plötzlich keine Treiber mehr.
Firmen wie u.a. Naim setzen wegen der Vorteile intern Linux ein; der HDX z.B. ist eigentlich ein PC, basierend auf einem Micro-ATX Board und eingebautem Dac. Hier hat Naim die Treibersoftware für den eigenen Dac natürlich selber geschrieben oder schreiben lassen.
Viele Grüße
Roland
Das wäre natürlich sehr gut für Audio geeignet. Man kann es konfigurieren nach Maß, schlank und rank, und kostenlos ist es auch...
Aber leider gibt es dafür zu wenig Treiber. Die müsste man sich fast alle selber schreiben - und Asiotreiber sind, wenn man es avanciert angeht, keineswegs trivial. Wir hätten für viele unserer Lieblingsgeräte also plötzlich keine Treiber mehr.
Firmen wie u.a. Naim setzen wegen der Vorteile intern Linux ein; der HDX z.B. ist eigentlich ein PC, basierend auf einem Micro-ATX Board und eingebautem Dac. Hier hat Naim die Treibersoftware für den eigenen Dac natürlich selber geschrieben oder schreiben lassen.
Viele Grüße
Roland
Hallo zusammen,
ein paar Dinge zur laufenden und sehr interessanten Diskussion möchte ich noch beisteuern:
Bei SPDIF gibt der Zuspieler-PC die Takt-Information dem SPDIF-Signal mit, sodass das Signal in den meisten Fällen arg verjittert ist (Quellen sind Stromversorgung, HF-Störnebel, CPU-Aktivitäte, Speicher-Zugriffe, HD-Zugriffe, etc. Hier ist dann eine Taktrekonstruktion im DAC und/oder mittels Big Ben unumgänglich.
ASIO hat da für meine Begriffe nur einen sehr geringen Anteil am Gesamtergebnis. Ich hatte mal ASIO4ALL laufen (was eine Kernel-Streaming-Variante darstellt. Ein klanglicher Unterschied war für mich nur ingeringem Maße feststellbar (und würde möglicherweise keinen Blindtest bestehen).
Bei cmp² besteht das Gesamtergebnis des überragenden Klanges durch eine Vielzahl von einzelnen Optimierungen, bei der jeder Schritt für sich genommen minimale Auswirkungen hat. Die Summe macht es dann. Den größten Anteil haben m.E. der Softwareeinsatz der cmp-Shell sowie des cplayers, die restlichen 30-40% ergeben sich aus zahlreichen OS- und Hardwaremodifikationen.
Ein cmp²-System spielt wesentlich sauberer als das Standard PC-System mit Foobar, obwohl der DAC das Einlesen der USB-Daten in den DAC steuert.
Noch sauberer aber spielt es, wenn ich FullXP mit Foobar (oder auch MinlogonXP + cmp²) über USB an Hiface und von dort via Big Ben an den DAC übergebe. Der DAC synchronisiert sich dabei auf den Big Ben.
Was Du dann unter Punkt 3 in Deinem Beitrag geschrieben hast (Klangergebnisse bei entsprechenden cmp²-Konfigurationen) deckt sich dann wieder auch mit meinen Erfahrungen. Hier ging es mir aber um Punkt 1 Deiner Ausführungen.
Grüße
Fujak
ein paar Dinge zur laufenden und sehr interessanten Diskussion möchte ich noch beisteuern:
Es gibt m.E. keinen prinzipiellen Vorteil von USB, wenn es um Jitter geht. Der eigentliche Vorteil ergibt sich erst, wenn nicht der Zuspieler-PC den Takt vorgibt, mit dem die Audio-Daten über den USB-Bus geschoben werden sondern der DAC mit seiner - hoffentlich präziseren - Clock (genannt asynchrone Übertragung).wgh52 hat geschrieben:Übertragung:
1. USB = Universal SERIAL Bus. Serielle Datenübertragung, Takt wird nicht getrennt übertragen.
2. SPDIF = Serielle Daten- und Taktübertragung. Daten und Takt "vermischt"
Beides müsste Jitteranfällig sein, ich verstehe den prinzipiellen Vorteil von USB nicht.
Bei SPDIF gibt der Zuspieler-PC die Takt-Information dem SPDIF-Signal mit, sodass das Signal in den meisten Fällen arg verjittert ist (Quellen sind Stromversorgung, HF-Störnebel, CPU-Aktivitäte, Speicher-Zugriffe, HD-Zugriffe, etc. Hier ist dann eine Taktrekonstruktion im DAC und/oder mittels Big Ben unumgänglich.
Keine Software kann dies. Aber eine Software kann die Entstehung von Jitter minimieren. Uli Brüggemann hat bereits ausgeführt, dass ASIO für sich genommen noch kein Garant ist für Jitterminimierung ist, sondern die Programmierung des ASIO-Treibers. Letztlich passiert im cmp²-System die eigentliche Jitter-Reduktion durch die Art des Speicherzugriffs, die Minimierung von CPU-Aktivitäten durch OS-Prozesse und durch gewisse Hardware-Modifikationen.wgh52 hat geschrieben:ASIO:
Wie kann eine Software den USB "entjittern"?
ASIO hat da für meine Begriffe nur einen sehr geringen Anteil am Gesamtergebnis. Ich hatte mal ASIO4ALL laufen (was eine Kernel-Streaming-Variante darstellt. Ein klanglicher Unterschied war für mich nur ingeringem Maße feststellbar (und würde möglicherweise keinen Blindtest bestehen).
Bei cmp² besteht das Gesamtergebnis des überragenden Klanges durch eine Vielzahl von einzelnen Optimierungen, bei der jeder Schritt für sich genommen minimale Auswirkungen hat. Die Summe macht es dann. Den größten Anteil haben m.E. der Softwareeinsatz der cmp-Shell sowie des cplayers, die restlichen 30-40% ergeben sich aus zahlreichen OS- und Hardwaremodifikationen.
Da kann ich nur gegenteilige Erfahrungen beisteuern. Das RME Fireface UC besitzt eine interne Clock, die sowohl bei USB als auch bei SPDIF eingesetzt werden kann. Man könnte also demnach davon ausgehen, dass das Fireface von einer möglichen Verjitterung aus dem PC immun sei. Es müsste demnach unerheblich sein, ob der PC-Zuspieler mit cmp² oder mit FullXP + Foobar läuft (beides USB + ASIO). In der Realität sind diese Unterschiede jedoch zu hören.analog+ hat geschrieben:1. Bei Einsatz eines Computers als Zuspieler macht es keinen Sinn, einen hochwertigen Dac mit guter Clock noch mal extern – über z.B. BigBen zu takten. Das verschlechtert sogar die Wiedergabe!
Ein cmp²-System spielt wesentlich sauberer als das Standard PC-System mit Foobar, obwohl der DAC das Einlesen der USB-Daten in den DAC steuert.
Noch sauberer aber spielt es, wenn ich FullXP mit Foobar (oder auch MinlogonXP + cmp²) über USB an Hiface und von dort via Big Ben an den DAC übergebe. Der DAC synchronisiert sich dabei auf den Big Ben.
Was Du dann unter Punkt 3 in Deinem Beitrag geschrieben hast (Klangergebnisse bei entsprechenden cmp²-Konfigurationen) deckt sich dann wieder auch mit meinen Erfahrungen. Hier ging es mir aber um Punkt 1 Deiner Ausführungen.
Grüße
Fujak
Hallo Uli,
Dass schreiben von ASIO Software Treibern ist in der Tat keine banale "Kleinigkeit" nebenbei. Die wenigen Entwickler die sich die Mühe machen und die Kosten dafür nicht scheuen, sieht man nicht im Mediamarkt.....
Ich bin auch darauf Aufmerksam geworden in der Periode wo ich Lynx verwende. 3 von 4 Updates meiner ehemaligen Lynx Two-B Karte haben einen deutlichen Klanggewinn gebracht. Das hat mich vorerst neugierig gemacht wie und warum Software so einen Einfluss auf Audioqualität hat....
In Bezug zu ASIO muss ich nochmals betonen das es zwei ganz Grundlegende Vorteile dieser Technik gibt.
1. Mit ASIO kommuniziert der Player mit der Soundkarte/DAC direkt auf der Hardwareabstraktionsschicht. D.h. windows mischt sich nicht in die Bufferung ein.
2. Der Umstand dass ASIO die feste Kontrolle des Clockings beherrscht, bringt den Player in "slave" -Modus. Und dass es in einer digitalen Audioübertragung nur einen Taktgeber geben darf, ist indiskutabel und wirklich ABC für jeden Tontechniker.
Im falle von cMP passt deine Theorie mit dem Speicher ein- und auslesen NICHT !
cicsmemoryplayer ist ein MEMORY-player und lädt den Speicher nur ein mal !!!
-da passiert kein ständiges ein/aus schreiben von Daten.
Um dies großzügig zu ermöglichen verwendet cPlay ein "Address Windowing Extensions" (AWE) um Windows einen reduzierten Zugang zum RAM geben. Der cMP Modus sieht auch vor die Prozesskerne so zu Teilen dass der eine für Audio kommunikation dient und der zweite Kern für andre Prozesse. Lupenreines Mulitasking also.
Desweiteren verwendet cPlay die L2 & L3 Cache des Prozessors als Speicher für seine weiteren Funktionen.
Ich weiss das man sich mit Behauptungen über Audioqualität schnell zu weit aus dem Fenster lehnt, aber cMP2 ist und bleibt ein sehr Intelligenter Weg zu digitalem High-end auf einem ganz neuen Niveau.
Dass schreiben von ASIO Software Treibern ist in der Tat keine banale "Kleinigkeit" nebenbei. Die wenigen Entwickler die sich die Mühe machen und die Kosten dafür nicht scheuen, sieht man nicht im Mediamarkt.....
Ich bin auch darauf Aufmerksam geworden in der Periode wo ich Lynx verwende. 3 von 4 Updates meiner ehemaligen Lynx Two-B Karte haben einen deutlichen Klanggewinn gebracht. Das hat mich vorerst neugierig gemacht wie und warum Software so einen Einfluss auf Audioqualität hat....
In Bezug zu ASIO muss ich nochmals betonen das es zwei ganz Grundlegende Vorteile dieser Technik gibt.
1. Mit ASIO kommuniziert der Player mit der Soundkarte/DAC direkt auf der Hardwareabstraktionsschicht. D.h. windows mischt sich nicht in die Bufferung ein.
2. Der Umstand dass ASIO die feste Kontrolle des Clockings beherrscht, bringt den Player in "slave" -Modus. Und dass es in einer digitalen Audioübertragung nur einen Taktgeber geben darf, ist indiskutabel und wirklich ABC für jeden Tontechniker.
Im falle von cMP passt deine Theorie mit dem Speicher ein- und auslesen NICHT !
cicsmemoryplayer ist ein MEMORY-player und lädt den Speicher nur ein mal !!!
-da passiert kein ständiges ein/aus schreiben von Daten.
Um dies großzügig zu ermöglichen verwendet cPlay ein "Address Windowing Extensions" (AWE) um Windows einen reduzierten Zugang zum RAM geben. Der cMP Modus sieht auch vor die Prozesskerne so zu Teilen dass der eine für Audio kommunikation dient und der zweite Kern für andre Prozesse. Lupenreines Mulitasking also.
Desweiteren verwendet cPlay die L2 & L3 Cache des Prozessors als Speicher für seine weiteren Funktionen.
Ich weiss das man sich mit Behauptungen über Audioqualität schnell zu weit aus dem Fenster lehnt, aber cMP2 ist und bleibt ein sehr Intelligenter Weg zu digitalem High-end auf einem ganz neuen Niveau.
Hallo Wilfried,
entscheidend ist, welcher Takt dem Signal "zugemischt" wird: Der des PC oder der vom Dac.
Damit letzteres funktioniert, braucht man einen (guten) Asiotreiber als Software auf der PC-Seite.
Und diese Software muss exakt mit dem Dac zusammenarbeiten.
Hardware und Software kann man nicht trennen, sie gehören zusammen.
Hier gibt es zwei Ansätze zur "Lösung" des Jitterproblems:
Erster : Jitter der Quelle ist egal, Reclocking löst das hinterher, Qualität bestimmt die Clock im Reclocker.
Zweiter: Quelle soll möglichst jitterarm laufen, die Taktung erfolgt durch den Dac, dessen Clock
bestimmt das Ergebnis.
Hallo Fujak,
natürlich reagiert der Fireface UC auf Jitter.
Deswegen hört man ja die Unterschiede zwischen zwischen xp+foobar, xp+cmp2 und xp+full-cmp2!
Nur:
Das Clocking einer Rosetta mittels Big Ben bringt keine Vorteile.
Ob die Apogee Rosetta, asynchron betrieben, ohne Reclocking nun vergleichbar, besser oder schlechter spielt als der FF UC mit dem BigBen als Reclocker werde ich nochmal untersuchen.
Viele Grüße
Roland
entscheidend ist, welcher Takt dem Signal "zugemischt" wird: Der des PC oder der vom Dac.
Damit letzteres funktioniert, braucht man einen (guten) Asiotreiber als Software auf der PC-Seite.
Und diese Software muss exakt mit dem Dac zusammenarbeiten.
Hardware und Software kann man nicht trennen, sie gehören zusammen.
Hier gibt es zwei Ansätze zur "Lösung" des Jitterproblems:
Erster : Jitter der Quelle ist egal, Reclocking löst das hinterher, Qualität bestimmt die Clock im Reclocker.
Zweiter: Quelle soll möglichst jitterarm laufen, die Taktung erfolgt durch den Dac, dessen Clock
bestimmt das Ergebnis.
Hallo Fujak,
natürlich reagiert der Fireface UC auf Jitter.
Deswegen hört man ja die Unterschiede zwischen zwischen xp+foobar, xp+cmp2 und xp+full-cmp2!
Nur:
Das Clocking einer Rosetta mittels Big Ben bringt keine Vorteile.
Ob die Apogee Rosetta, asynchron betrieben, ohne Reclocking nun vergleichbar, besser oder schlechter spielt als der FF UC mit dem BigBen als Reclocker werde ich nochmal untersuchen.
Viele Grüße
Roland
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4665
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo Leif,
der Datenaustausch mit dem ASIO Treiber erfolgt über die schon beschriebenen Puffer, siehe bitte mal in die entsprechende Spezifikation bei Steinberg. Da ich ja ebenfalls in meiner Software ASIO-Treiber anspreche, behaupte ich einfach mal,das zu wissen
Nun ist dieser Puffer ein Teil des Speichers. Ganz bestimmt nicht ein Speicher mit eigener Adressierung oder gar eigenem Speicherchip. Sondern Teil des RAM.
Eine Software wie cPlay oder cmP mag nun dafür sorgen, dass dieser Speicher vielleicht in einem Bereich liegt, wo andere Tasks nicht direkt mit befasst sind. Aber trotzdem hängen die Speicherchips am gleichen Daten- und Adressbus.
Im übrigen ist es eigentlich egal ob die Daten nun von der Festplatte oder von einem anderen Speicherbereich (Memoryplayer) in den Puffer kommen. Hauptsache sie gehen über den ASIO-Puffer.
Und was sich auf dem Bus tut, da hat auch cmP keine wirkliche Kontrolle darüber. Ausser, dass eben die Anzahl der Prozesse verringert wird, Dienste ausser Kraft gesetzt werden oder die Musik vorher in den Speicher reingelesen wird, damit die Tasks zum Auslesen der Festplatte wegfallen und vielleicht nicht das Klappern des Lesekopfes in die Stromversorgung reinspuckt (sinnbildlich gesehen).
Und wie sich zumindest langsam als allgemeine Erkenntnis durchsetzt: hinter den Puffern kommt noch der ASIO-Treiber selbst. Wie dieser nun das Betriebssystem aushebelt, damit es mindestmöglichst dazwischenfunkt? Tja, ich fände es prima, da mal was darüber zu lesen. Aber das scheint nicht als Allgemeinwissen im WWW publiziert zu sein.
Grüsse, Uli
der Datenaustausch mit dem ASIO Treiber erfolgt über die schon beschriebenen Puffer, siehe bitte mal in die entsprechende Spezifikation bei Steinberg. Da ich ja ebenfalls in meiner Software ASIO-Treiber anspreche, behaupte ich einfach mal,das zu wissen
Nun ist dieser Puffer ein Teil des Speichers. Ganz bestimmt nicht ein Speicher mit eigener Adressierung oder gar eigenem Speicherchip. Sondern Teil des RAM.
Eine Software wie cPlay oder cmP mag nun dafür sorgen, dass dieser Speicher vielleicht in einem Bereich liegt, wo andere Tasks nicht direkt mit befasst sind. Aber trotzdem hängen die Speicherchips am gleichen Daten- und Adressbus.
Im übrigen ist es eigentlich egal ob die Daten nun von der Festplatte oder von einem anderen Speicherbereich (Memoryplayer) in den Puffer kommen. Hauptsache sie gehen über den ASIO-Puffer.
Und was sich auf dem Bus tut, da hat auch cmP keine wirkliche Kontrolle darüber. Ausser, dass eben die Anzahl der Prozesse verringert wird, Dienste ausser Kraft gesetzt werden oder die Musik vorher in den Speicher reingelesen wird, damit die Tasks zum Auslesen der Festplatte wegfallen und vielleicht nicht das Klappern des Lesekopfes in die Stromversorgung reinspuckt (sinnbildlich gesehen).
Und wie sich zumindest langsam als allgemeine Erkenntnis durchsetzt: hinter den Puffern kommt noch der ASIO-Treiber selbst. Wie dieser nun das Betriebssystem aushebelt, damit es mindestmöglichst dazwischenfunkt? Tja, ich fände es prima, da mal was darüber zu lesen. Aber das scheint nicht als Allgemeinwissen im WWW publiziert zu sein.
Grüsse, Uli
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4665
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
nein.play-mate hat geschrieben:-bedeutet dass das du auch die Word-Clock vom BigBen über BNC an den RME legst ?
Ich benutze auch einen BigBen. Das spdif- bzw. AES-Signal geht rein in den BigBen und kommt neu als spdif- oder AES-Signal getaktet wieder raus. Und der DAC bekommt nun dieses neue Signal, darauf sync't er sich.
Grüsse, Uli
Hallo Uli,
bezüglich Asio-Programmierung habe ich mich mal mit Makus Medau von Ploytec unterhalten, die schreiben u.a. die Treiber für bekannte Firmen im Studiobereich.
Das ist alles andere als trivial - verstanden habe ich bestenfalls die Hälfte, jedenfalls muss man da sehr weit in das Betriebssystem einsteigen und immer die Geräte dokumentiert zur Verfügung haben, für die Treiber entstehen sollen. Es gibt nicht viele, die sowas machen. Der USB-Treiber für Windows (nicht zu verwechseln mit dem Asio-Treiber), den u.a. Ayre einsetzt um 192 Khz abholen zu können, stammt übrigens von einer Firma aus Sachsen-Anhalt...
Jedenfalls steckt das Know-How solcher Leute wie immer im Detail. Und das wird natürlich nicht verraten.
Viele Grüße
Roland
bezüglich Asio-Programmierung habe ich mich mal mit Makus Medau von Ploytec unterhalten, die schreiben u.a. die Treiber für bekannte Firmen im Studiobereich.
Das ist alles andere als trivial - verstanden habe ich bestenfalls die Hälfte, jedenfalls muss man da sehr weit in das Betriebssystem einsteigen und immer die Geräte dokumentiert zur Verfügung haben, für die Treiber entstehen sollen. Es gibt nicht viele, die sowas machen. Der USB-Treiber für Windows (nicht zu verwechseln mit dem Asio-Treiber), den u.a. Ayre einsetzt um 192 Khz abholen zu können, stammt übrigens von einer Firma aus Sachsen-Anhalt...
Jedenfalls steckt das Know-How solcher Leute wie immer im Detail. Und das wird natürlich nicht verraten.
Viele Grüße
Roland