Dieser Thread soll die parallel im JPlay-Thread und im Asus-DAC-Thread entstandene Diskussion über ASIO und asynchronen Modus bündeln, da sie dort jeweils zu sehr ins off-topic geht. Es lässt sich leider dabei nicht vermeiden, wenn der ein oder andere Beitrag z.T. aus dem Zusammenhang fällt. Ich bitte um Verständnis. Dafür kann dann hier zum Thema nach Herzenlust weiterdiskutiert werden.
Grüße
Fujak
Hallo zusammen,
leider wird auch hier wieder zweierlei durcheinandergebracht: das softwareseitige Schnittstellenprotokoll Asio und das hardwareseitige USB-Übertragungsprotokoll "isochrone Übertragung mit asynchronen Endpunkten" (kurz asynchroner Modus genannt), bei dem DAC und PC in eine Master-Slave-Korrelation treten (DAC gibt den Takt für den USB-Bus vor, PC synchronisiert sich darauf). Letzteres ist für den klanglichen Zugewinn verantwortlich und nicht ein Treiber-Protokoll. Die meisten preiswerten USB-DACs mit Asio-Treiber (ohne Async-Modus) offenbaren größte Unterschiede zwischen cMP²/JPlay auf der einen Seite und Playern wie Foobar auf der anderen Seite.
Um nicht das ganze doppelt zu posten, hier der Link zu meiner ausführlicheren Stellungnahme: http://www.aktives-hoeren.de/viewtopic. ... 988#p52988
Grüße
Fujak
ASIO und asynchrone Übertragung
Hallo Uli,
...die Daten wandern zusammen mit der Clock über I2S vom USB-Empfänger zum DAC-IC...
Das ist nicht ganz richtig: Über USB wird hier ein reines Datenprotokoll gefahren, der Takt ist nicht Bestandteil des Protokolls wie bei SPDIF (die USB-Schnittstelle ist rückkanalfähig, es können über sie unterschiedliche Protokolle geschickt werden).
Der Asiotreiber sorgt über den Rückkanal nur dafür, daß die Dac-Clock die Aus- und Eingangsbuffer von PC und Dac steuert (die können dadurch klein gehalten werden).
Der Takt muß nicht aus dem Protokoll "rückgewonnen" werden, er wird dem Empfänger lediglich im Header der gesendeten Datenpakte mitgeteilt.
Die PLL im Dac muß sich daher nicht wie bei SPDIF auf den ankommenden Takt synchronisieren, sondern taktet mit Ihrer eigenen Clock die eingegangenen Datenpakete. Der DA-Wandlerbaustein im Dac ist über I2S angebunden: Zwei Kanäle (Leitungen) für die Daten und eine für den Takt der Dac-Clock.
(I2S ist eine interne Schnittstelle mit Protokoll von Philips aus den siebzigern, gedacht zur Kommunikation zwischen Digitalbausteinen auf der Platine).
Die SPDIF-Schnittstelle des Hiface ist übrigens das Ergebnis eines asynchronen Modus vorher, die Qualität bestimmt dessen Realisierung, um es mal so auszudrücken. Die cmp-ler kennen das von der Esi-Juli-Karte: Die sitzt im Rechner über Asio asynchron angebunden und liefert je nach Qualität der Kiste ein sauberes SPDIF-Signal.
Logischerweise hängt in beiden Fällen die erzielbare Qualität auch von der der Karten-Clock ab, deren Stromversorgung ist dabei natürlich wichtig.
Nur am Rande: Ein Vorteil von SPDIF ist die Möglichkeit der galvanischen Trennung, über AES-EBU oder Toslink. Das geht bei USB leider nicht so einfach, jedenfalls nicht für HiRes. Aber das ist wieder eine andere Baustelle.
Viele Grüße
Roland
...die Daten wandern zusammen mit der Clock über I2S vom USB-Empfänger zum DAC-IC...
Das ist nicht ganz richtig: Über USB wird hier ein reines Datenprotokoll gefahren, der Takt ist nicht Bestandteil des Protokolls wie bei SPDIF (die USB-Schnittstelle ist rückkanalfähig, es können über sie unterschiedliche Protokolle geschickt werden).
Der Asiotreiber sorgt über den Rückkanal nur dafür, daß die Dac-Clock die Aus- und Eingangsbuffer von PC und Dac steuert (die können dadurch klein gehalten werden).
Der Takt muß nicht aus dem Protokoll "rückgewonnen" werden, er wird dem Empfänger lediglich im Header der gesendeten Datenpakte mitgeteilt.
Die PLL im Dac muß sich daher nicht wie bei SPDIF auf den ankommenden Takt synchronisieren, sondern taktet mit Ihrer eigenen Clock die eingegangenen Datenpakete. Der DA-Wandlerbaustein im Dac ist über I2S angebunden: Zwei Kanäle (Leitungen) für die Daten und eine für den Takt der Dac-Clock.
(I2S ist eine interne Schnittstelle mit Protokoll von Philips aus den siebzigern, gedacht zur Kommunikation zwischen Digitalbausteinen auf der Platine).
Die SPDIF-Schnittstelle des Hiface ist übrigens das Ergebnis eines asynchronen Modus vorher, die Qualität bestimmt dessen Realisierung, um es mal so auszudrücken. Die cmp-ler kennen das von der Esi-Juli-Karte: Die sitzt im Rechner über Asio asynchron angebunden und liefert je nach Qualität der Kiste ein sauberes SPDIF-Signal.
Logischerweise hängt in beiden Fällen die erzielbare Qualität auch von der der Karten-Clock ab, deren Stromversorgung ist dabei natürlich wichtig.
Nur am Rande: Ein Vorteil von SPDIF ist die Möglichkeit der galvanischen Trennung, über AES-EBU oder Toslink. Das geht bei USB leider nicht so einfach, jedenfalls nicht für HiRes. Aber das ist wieder eine andere Baustelle.
Viele Grüße
Roland
Hallo Fujak,
jetzt mal keine Spitzfindigkeiten im Kontext.
Wir reden hier von Asiotreibern, die mit dem asynchronen Modus arbeiten - nicht mehr und nicht weniger.
Der Ayre (wie übrigens auch andere, preiswerte Teile) arbeiten "hardwareseitig" asynchron, ohne Buffersteuerung. Die ist klanglich relevant.
Viele Grüße
Roland
jetzt mal keine Spitzfindigkeiten im Kontext.
Wir reden hier von Asiotreibern, die mit dem asynchronen Modus arbeiten - nicht mehr und nicht weniger.
Der Ayre (wie übrigens auch andere, preiswerte Teile) arbeiten "hardwareseitig" asynchron, ohne Buffersteuerung. Die ist klanglich relevant.
Viele Grüße
Roland
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4009
- Registriert: 04.05.2010, 19:37
Hallo,
Mittels ASIO wird es einer entsprechenden Software (Treiber) ermöglicht, auf die Multi-channel-Fähigkeiten vieler Sound- und Recordingkarten zuzugreifen.
Der notwendige Rückkanal bei asynchroner Taktung hat nichts mit den Multi-channel-Fähigkeiten der Soundkarte oder Asio zu tun, sondern ist Teil der USB-Technik und damit einer von den max. 31 Endpunkten bei USB-Geräten.
Für asynchronen USB-Modus braucht es daher keinen ASIO-Treiber, es bedarf eines Treiber, der den USB-Audiocontroller für den Rückkanal aktiviert.
Gruß
Bernd Peter
Audio Stream Input/Output (ASIO) ist ein vom Audio-Spezialisten Steinberg entwickeltes, mehrkanalfähiges Audiotransfer-Protokoll.Der Asiotreiber sorgt über den Rückkanal nur dafür, daß die Dac-Clock die Aus- und Eingangsbuffer von PC und Dac steuert (die können dadurch klein gehalten werden).
Mittels ASIO wird es einer entsprechenden Software (Treiber) ermöglicht, auf die Multi-channel-Fähigkeiten vieler Sound- und Recordingkarten zuzugreifen.
Der notwendige Rückkanal bei asynchroner Taktung hat nichts mit den Multi-channel-Fähigkeiten der Soundkarte oder Asio zu tun, sondern ist Teil der USB-Technik und damit einer von den max. 31 Endpunkten bei USB-Geräten.
Für asynchronen USB-Modus braucht es daher keinen ASIO-Treiber, es bedarf eines Treiber, der den USB-Audiocontroller für den Rückkanal aktiviert.
Gruß
Bernd Peter
USB DAC Asus Xonar Essence One
Hallo,
"Der Asiotreiber sorgt über den Rückkanal nur dafür, daß die Dac-Clock die Aus- und Eingangsbuffer von PC und Dac steuert (die können dadurch klein gehalten werden)."
Grüße
Roland
"Der Asiotreiber sorgt über den Rückkanal nur dafür, daß die Dac-Clock die Aus- und Eingangsbuffer von PC und Dac steuert (die können dadurch klein gehalten werden)."
Grüße
Roland
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4009
- Registriert: 04.05.2010, 19:37
Hallo Bernd-Peter,
klar.
Ein Asio-Treiber erfordert zwingend den asnynchronen Modus, aber der asynchrone Modus nicht zwingend einen Asio-Treiber.
Asynchron heißt ja erstmal nur, daß Sender und Empfänger unabhängig voneinander laufen.
Jeder Streamer arbeitet asynchron, das Netzwerkprotokoll ist ein Datenprotokoll.
Wer´s genau wissen will, findet hier wirklich alles über USB:
http://www.beyondlogic.org/usbnutshell/usb1.shtml.
Viele Grüße
Roland
klar.
Ein Asio-Treiber erfordert zwingend den asnynchronen Modus, aber der asynchrone Modus nicht zwingend einen Asio-Treiber.
Asynchron heißt ja erstmal nur, daß Sender und Empfänger unabhängig voneinander laufen.
Jeder Streamer arbeitet asynchron, das Netzwerkprotokoll ist ein Datenprotokoll.
Wer´s genau wissen will, findet hier wirklich alles über USB:
http://www.beyondlogic.org/usbnutshell/usb1.shtml.
Viele Grüße
Roland
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4009
- Registriert: 04.05.2010, 19:37
Hallo Fujak,
Sorry, da werden wir uns streiten müssen.
Der Ayre benötigt kein ASIO, aber USB Audio Class 2 (mit Ploytech Treiber um dies in Windows zu ermöglichen) USB AudioClass 2 ist funktionier genau so wie ASIO. Als Bus und daher als Datenverbindung.
Und Softwareprotokol und Schnittstellen bringe ich nicht durcheinander. Im Gegenteil.
Seit Jahren gibt im Profibereich ASIO für Windows weil Microsoft nicht in der Lage war ein asynchrones Protokol zu gewährleisten. Windows hat immer seine eigenen API Protokolle gehabt : DS; KernelStreaming und WASAPI). Alle diese Softwareprotokolle sind nicht asynchron und daher minderwertig bzw. kompromisbehaftet weil das Betriebssystem/der Computer das Clocking für diese Übertragung gewährt.
Diese Protokolle sind auch "Streaming" Schnitstellen weil sie ein zeitkritisches Signal an einen DAC liefern.
Ein Bus ist dagegen eine Datenverbindung. PCI, PCIe, SATA, USB, FireWire sind z.B. alle gesammt Datenverbindungen.
Kein digitales Gerät kann eine Datenverbindung nutzen ohne ein Kommunikationsprotokol !
-diese ist schlichtweg die Grundlage für die Nutzung eines sollchen.
USB ist (auch) ein Plug ´n Play Schnittstelle die der Computer auf anhieb erkennt. Dies ist eine Besonderheit bei USB. Das USB Audio Class 2 das neuerdings bei vielen DAC Herstellern via z.B. XMOS oder M2Tech bereitgestellt wird, braucht hier auch kein Treiber (gemäß Plug n´Play).
ASIO ist gewiss für Mehrkanal und D/A & A/D in/out als Protokoll-Vorlage von Steinberg konzepiert, aber es bedarf immer einen proprietären Softwaretreiber der (-und dies ist ganz wichtig) vom Hersteller des DACs/Soundkarte 100% entwickelt wird. Nur somit erhält der Hersteller die volle Kontrolle über seine Hardware und dessen genaue Funktionsweise & Performance.
Diese Schnitstelle ist IMMER asynchron, und sie läuft IMMER über einen Bus (also USB, FireWire, PCI...etc.)
Nun habe ich seit fast 2 Jahren versucht diese Tematik begreiflich zu machen. Vieleicht nicht immer pädagogisch genug, aber mitlerweile platzt mir der Kragen.
-wenn hier einer irgendwas nicht versteht oder irgendwie etwas anderes glaubt, dann ist es schade drum.
Man kann doch nicht in diesem Forum ständig behaupten das die Erde flach oder viereckig ist.....
ASIO ist immer asynchron !
Vielen Dank für die Aufmerksamkeit.
L.
Sorry, da werden wir uns streiten müssen.
Der Ayre benötigt kein ASIO, aber USB Audio Class 2 (mit Ploytech Treiber um dies in Windows zu ermöglichen) USB AudioClass 2 ist funktionier genau so wie ASIO. Als Bus und daher als Datenverbindung.
Und Softwareprotokol und Schnittstellen bringe ich nicht durcheinander. Im Gegenteil.
Seit Jahren gibt im Profibereich ASIO für Windows weil Microsoft nicht in der Lage war ein asynchrones Protokol zu gewährleisten. Windows hat immer seine eigenen API Protokolle gehabt : DS; KernelStreaming und WASAPI). Alle diese Softwareprotokolle sind nicht asynchron und daher minderwertig bzw. kompromisbehaftet weil das Betriebssystem/der Computer das Clocking für diese Übertragung gewährt.
Diese Protokolle sind auch "Streaming" Schnitstellen weil sie ein zeitkritisches Signal an einen DAC liefern.
Ein Bus ist dagegen eine Datenverbindung. PCI, PCIe, SATA, USB, FireWire sind z.B. alle gesammt Datenverbindungen.
Kein digitales Gerät kann eine Datenverbindung nutzen ohne ein Kommunikationsprotokol !
-diese ist schlichtweg die Grundlage für die Nutzung eines sollchen.
USB ist (auch) ein Plug ´n Play Schnittstelle die der Computer auf anhieb erkennt. Dies ist eine Besonderheit bei USB. Das USB Audio Class 2 das neuerdings bei vielen DAC Herstellern via z.B. XMOS oder M2Tech bereitgestellt wird, braucht hier auch kein Treiber (gemäß Plug n´Play).
ASIO ist gewiss für Mehrkanal und D/A & A/D in/out als Protokoll-Vorlage von Steinberg konzepiert, aber es bedarf immer einen proprietären Softwaretreiber der (-und dies ist ganz wichtig) vom Hersteller des DACs/Soundkarte 100% entwickelt wird. Nur somit erhält der Hersteller die volle Kontrolle über seine Hardware und dessen genaue Funktionsweise & Performance.
Diese Schnitstelle ist IMMER asynchron, und sie läuft IMMER über einen Bus (also USB, FireWire, PCI...etc.)
Nun habe ich seit fast 2 Jahren versucht diese Tematik begreiflich zu machen. Vieleicht nicht immer pädagogisch genug, aber mitlerweile platzt mir der Kragen.
-wenn hier einer irgendwas nicht versteht oder irgendwie etwas anderes glaubt, dann ist es schade drum.
Man kann doch nicht in diesem Forum ständig behaupten das die Erde flach oder viereckig ist.....
ASIO ist immer asynchron !
Vielen Dank für die Aufmerksamkeit.
L.
Hallo Leif,
Und auch umgekehrt gibt es asynchrone USB-DACs (Ayre, Wavelength etc.) die mit eigenen programmierten FPGAs ganz ohne Asio auskommen. Die koppeln sich hörbar von dem ab, was an Störnebel im PC passiert (sprich: denen ist es herzlich egal, wieviel Dienste man im PC abschaltet oder mit welchem Player man die Daten rendert - sie klingen immer gleich gut).
Grüße
Fujak
keep cool; es geht hier doch nur um unterschiedliche technische Positionen. Da müsste mir ja auch seit 2 Jahren der Kragen platzen, wenn ich Deine Erläuterungen lese...play-mate hat geschrieben:Nun habe ich seit fast 2 Jahren versucht diese Tematik begreiflich zu machen. Vieleicht nicht immer pädagogisch genug, aber mitlerweile platzt mir der Kragen.
ich weiß, dass Du diese These seit Jahren predigst, und ebenso lange überzeugt sie mich nicht. Denn ich brauche nur auf den Markt schauen: Da gibt es billige externe USB-Interface (wie z.B. die Terratec-Interfaces); die arbeiten mit Asio-Treibern, weisen aber keinen asynchrone USB-Übertragungsmodus auf und sind entsprechend anfällig für jeden Störnebel, der aus dem PC kommt (das hört man dann auch).play-mate hat geschrieben:ASIO ist immer asynchron !
Und auch umgekehrt gibt es asynchrone USB-DACs (Ayre, Wavelength etc.) die mit eigenen programmierten FPGAs ganz ohne Asio auskommen. Die koppeln sich hörbar von dem ab, was an Störnebel im PC passiert (sprich: denen ist es herzlich egal, wieviel Dienste man im PC abschaltet oder mit welchem Player man die Daten rendert - sie klingen immer gleich gut).
Grüße
Fujak
Fujak,
nochmal: Auch ein Streamer arbeitet ohne Asio asynchron - für den asynchronen Modus braucht man keinen Asiotreiber.
Die von Dir angesprochenen billigen Soundkarten arbeiten, ähnlich wie Asio4all, mit einem generischen Asiotreiber für unterschiedliche Karten. Der setzt auf dem Windows-Kernelstreaming-Layer auf. Die Asio 2.0-Treiber, von denen wir hier reden, tun dies nicht und sind immer gerätespezifisch.
Auch hier gibt es aber klangliche Unterschiede, es hängt davon ab, wie sauber der Treiber programmiert ist. Der des Dr.Dac Prime ist dafür ein Beispiel.
Das ist aber keine Frage des Prinzips.
Der Ayre arbeitet anders, der verwendet ein modifiziertes USB-Datenprotokoll - logischerweise asynchron...
Das FPGA dient zur Realisierung von Ayres Digitalfiltertechnik, und in Zusammenhang z.B. mit der galvanischen Trennung der Eingänge wird das Ergebnis natürlich sehr gut! (-s. Ayre-WhitePape)r.
Viele Grüße
Roland
nochmal: Auch ein Streamer arbeitet ohne Asio asynchron - für den asynchronen Modus braucht man keinen Asiotreiber.
Die von Dir angesprochenen billigen Soundkarten arbeiten, ähnlich wie Asio4all, mit einem generischen Asiotreiber für unterschiedliche Karten. Der setzt auf dem Windows-Kernelstreaming-Layer auf. Die Asio 2.0-Treiber, von denen wir hier reden, tun dies nicht und sind immer gerätespezifisch.
Auch hier gibt es aber klangliche Unterschiede, es hängt davon ab, wie sauber der Treiber programmiert ist. Der des Dr.Dac Prime ist dafür ein Beispiel.
Das ist aber keine Frage des Prinzips.
Der Ayre arbeitet anders, der verwendet ein modifiziertes USB-Datenprotokoll - logischerweise asynchron...
Das FPGA dient zur Realisierung von Ayres Digitalfiltertechnik, und in Zusammenhang z.B. mit der galvanischen Trennung der Eingänge wird das Ergebnis natürlich sehr gut! (-s. Ayre-WhitePape)r.
Viele Grüße
Roland
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
How do we connect a DAC to a PC?
Say we have a SPDIF output and a USB output.
We have a DAC with a SPDIF input and a USB input.
One thing is obvious, no matter what driver we use, be it DS, WASAPI, ASIO, etc, they are all software.
What happens is that the audio is spooled from memory over the PCI to the SPDIF header.
This header is driven by a clock.
If this clock runs with 10 ns intrinsic jitter, it runs with 10 ns intrinsic jitter and no way for the software to improve on it. Software can’t improve the properties of our hardware.
Regardless of the software drive used, as a minimum we will have 10 ns input jitter at the DAC.
If we are using USB the data is spooled from memory over the PCI to an internal USB hub and from there to the USB DAC.
This bus runs at a fixed speed e.g. 480 MHz.
In case of USB audio, be it UAC1 or UAC2 an isochronous stream is maintained.
The frames contain as much data as is needed for the DAC to play.
But we do have 2 timed events, the amount of data generated and the clock driving the DAC.
In adaptive mode the clock of the DAC is varied to avoid buffer over/under run.
In async mode a feedback loop is established to regulated the amount of data send by the PC.
Notice that adaptive and async mode are properties of the USB audio protocol.
Notice that the audio driver used be it DS, WASAPI, ASIO, etc has nothing but nothing to do with the synchronization used in the USB.
Audio drivers can’t affect the USB protocol, they simply fill a buffer in memory.
Say we have a SPDIF output and a USB output.
We have a DAC with a SPDIF input and a USB input.
One thing is obvious, no matter what driver we use, be it DS, WASAPI, ASIO, etc, they are all software.
What happens is that the audio is spooled from memory over the PCI to the SPDIF header.
This header is driven by a clock.
If this clock runs with 10 ns intrinsic jitter, it runs with 10 ns intrinsic jitter and no way for the software to improve on it. Software can’t improve the properties of our hardware.
Regardless of the software drive used, as a minimum we will have 10 ns input jitter at the DAC.
If we are using USB the data is spooled from memory over the PCI to an internal USB hub and from there to the USB DAC.
This bus runs at a fixed speed e.g. 480 MHz.
In case of USB audio, be it UAC1 or UAC2 an isochronous stream is maintained.
The frames contain as much data as is needed for the DAC to play.
But we do have 2 timed events, the amount of data generated and the clock driving the DAC.
In adaptive mode the clock of the DAC is varied to avoid buffer over/under run.
In async mode a feedback loop is established to regulated the amount of data send by the PC.
Notice that adaptive and async mode are properties of the USB audio protocol.
Notice that the audio driver used be it DS, WASAPI, ASIO, etc has nothing but nothing to do with the synchronization used in the USB.
Audio drivers can’t affect the USB protocol, they simply fill a buffer in memory.
Lieber Fujak,
Das genau du nicht viel von ASIO hälst, sollte jedem der dein digitales Patchwork aus BigBen, USB, S/PDIF und KernelStreaming in Augenschein genommen hat, klar sein. Das du deine Haltung oder Überzeugung verteidigst ist auch ganz legitim.
Es soll mich aber nicht daran hindern (falls du mich nicht Sperrst, Löscht oder andersweitig zum Schweigen bringst) meine Ansichten zu der technischen Überlegenheit von ASIO im Vergleich zu Windows API´s zu propagieren.
Vorweg hat dein Beispiel Terratec ASIO nichts mit der Problematik "asynchron" zu tun.
Auch wenn ein Interface nicht in verschiedene Clock-Modi eingestellt werden kann, oder es von einem asynchronen Modus bei Terratec die Rede ist, so ist ein ASIO-Gerät (Clock-bezogen) immer asynchron bzw. unabhängig von der Clock des Computers.
Weiter kann ich nicht erkennen dass Gordon Rankin´s Ayre DAC irgendetwas mit einen FPGA zu tun haben soll.
Die technische Erklärung zum async USB Verfahren von Ayre ist hier zu lesen :
http://www.ayre.com/pdf/Ayre_USB_DAC_White_Paper.pdf
-aber bitte : ich bin gespannt wo du von einem FPGA in diesem Zusammenhang erfahren hast.
Aber nochmals zu ASIO und wie es funktioniert.
Dazu erst einige Vorraussetzungen zu Treiber und Windows die aus Wikipedia zitiert sind.
Generische Treiber für Audio, Video und GameController werden Windows API´s genannt (http://de.wikipedia.org/wiki/Windows_API) zu denen folgende gehören:
Direct Sound
MME :
KernelStreaming (KS)
WASAPI
Die Playersoftware bindet sich zu sollch einem Treiber um die Kommunikation zur Audio-Hardware zu etablieren. Dabei verwendet diese Kombination (Player und Treiber) die eingebaute Clock des Computers (die bekanntlich nicht ausgesprochen jitterarm ist).
In anderen Worten : mit einem generischen Windowstreiber ist der Computer der Master und das Interface nimmt ein Audiostream vom PC an. Bei DS und MME wird das Signal durch den K-Mixer geschickt und evt. resampled. Bei WASAPI und KS wird der Mixer zwar umgangen, aber die Taktung liegt immer noch beim Windows Betriebssystem.
Dies kann man sehr einfach Überprüfen in dem man bei einem generischen Windowstreiber im Gerätemanager den "Systemzeitgeber" deaktiviert. Dann läuft nix mehr.
Bei ASIO läuft dann noch alles bestens.
ASIO :
Steinbergs ASIO Standard ist eine Normierung wie ein Gerätehersteller seine proprietäre Software an einen Windows Computer auf der HAL-Ebene (Hardwareabstraktionsschicht) programmieren kan
Die Norm sieht auch verschiedene Einhaltungsstandards wie Latenz und Buffers vor, aber ganz grundsätzlich ist die Norm um die Kommunikation mit Windows zu gewähren OHNE damit auf die Windowssoftware zurück zu greifen.
Dafür setzt das ASIO Gerät auf die Hardwareabstraktionsschicht auf und isoliert sich von allen Teilen des Betriebssystems. Dies heisst z.B. dass in einem PC mit einer ASIO Soundkarte/Interface gibt es nun 2 unabhängige Geräte die beide auf der Computerplatine sitzen (entweder über USB, FireWire oder PCI). Dies ist auch im Gerätemanager ausgewiesen.
Weil ein ASIO Gerät auf der HAL via einem Datenbus angedockt ist, kann die Kommunikation zum PC NUR in Datenpakete vorgehen. Da es keine Taktung einer Clock in so einem Modus gibt, wird der Taktgeber zwangsläuffig die Soundkarte/Interface sein.
Also eine asynchrone Taktung !!
Die asynchone USB Audio Class 2, die es über Apple´s CoreAudio und Linux schon lange gibt, ist ein ganz anderes Thema, geehrter Fujak.
Vincent´s "Welltemperedcomputer.com" beleuchtet USB Audio sehr verständlich.
Mit hochachtungsvollen Grüße
Leif
Das genau du nicht viel von ASIO hälst, sollte jedem der dein digitales Patchwork aus BigBen, USB, S/PDIF und KernelStreaming in Augenschein genommen hat, klar sein. Das du deine Haltung oder Überzeugung verteidigst ist auch ganz legitim.
Es soll mich aber nicht daran hindern (falls du mich nicht Sperrst, Löscht oder andersweitig zum Schweigen bringst) meine Ansichten zu der technischen Überlegenheit von ASIO im Vergleich zu Windows API´s zu propagieren.
Vorweg hat dein Beispiel Terratec ASIO nichts mit der Problematik "asynchron" zu tun.
Auch wenn ein Interface nicht in verschiedene Clock-Modi eingestellt werden kann, oder es von einem asynchronen Modus bei Terratec die Rede ist, so ist ein ASIO-Gerät (Clock-bezogen) immer asynchron bzw. unabhängig von der Clock des Computers.
Weiter kann ich nicht erkennen dass Gordon Rankin´s Ayre DAC irgendetwas mit einen FPGA zu tun haben soll.
Die technische Erklärung zum async USB Verfahren von Ayre ist hier zu lesen :
http://www.ayre.com/pdf/Ayre_USB_DAC_White_Paper.pdf
-aber bitte : ich bin gespannt wo du von einem FPGA in diesem Zusammenhang erfahren hast.
Aber nochmals zu ASIO und wie es funktioniert.
Dazu erst einige Vorraussetzungen zu Treiber und Windows die aus Wikipedia zitiert sind.
"Die Hauptaufgabe von Gerätetreibern ist das Bereitstellen von hardwarenahen Funktionen durch die Hardwareabstraktionsschicht. Alle Arten von Geräten sind unterschiedlich, selbst Geräte, die denselben Zweck erfüllen. Sogar die verschiedenen Modelle eines Gerätes desselben Herstellers, die zum Beispiel neue Funktionen oder mehr Leistung versprechen, werden oft völlig anders angesteuert.
Von Computern und ihren Betriebssystemen kann nicht erwartet werden, dass sie mit all diesen verschiedenen Arten umgehen können, erst recht nicht mit zukünftigen Geräten. Um dieses Problem zu lösen, gibt das Betriebssystem vor, wie eine Klasse von Geräten angesprochen werden sollte. Die Gerätetreiber kümmern sich dann um die Übersetzung dieser Funktionsaufrufe des Betriebssystems in gerätespezifische Steuersignale. Theoretisch sollte also auch ein völlig neues Gerät mit völlig neuer Ansteuerung problemlos funktionieren, sobald ein Treiber für dieses Gerät vorliegt.
Oft existieren viele verschiedene Varianten eines Treibers, in erster Linie abhängig von der unterstützten Hardware, oft auch in verschiedenen (Entwicklungs-)Versionen. Zudem muss für jedes unterstützte Betriebssystem eine Variante existieren, da die Schnittstellen hierzu zum Beispiel bei Microsoft Windows oder Linux stark unterschiedlich sind. Weiterhin besteht eine Abhängigkeit von der grundlegenden Architektur des Rechners und des Betriebssystems, auch von der Verarbeitungsbandbreite.
Einen Gerätetreiber zu programmieren gilt in den meisten Fällen als Herausforderung, da es ein eingehendes Verständnis der Funktionsweise einer Plattform erfordert, sowohl auf der Hardware- wie der Softwareseite.
Normalerweise werden Gerätetreiber daher von den Hardwareherstellern selbst geschrieben, da nur sie das genaue Design der Hardware kennen.
Sogenannte Klassentreiber (auch generische Treiber genannt) sind weitestgehend herstellerunabhängig. Oft genannte Beispiele hierfür sind Klassentreiber für Drucker oder für die Geräteklassen, die am Universal-Serial-Bus angeschlossen werden können."
Generische Treiber für Audio, Video und GameController werden Windows API´s genannt (http://de.wikipedia.org/wiki/Windows_API) zu denen folgende gehören:
Direct Sound
MME :
KernelStreaming (KS)
WASAPI
Die Playersoftware bindet sich zu sollch einem Treiber um die Kommunikation zur Audio-Hardware zu etablieren. Dabei verwendet diese Kombination (Player und Treiber) die eingebaute Clock des Computers (die bekanntlich nicht ausgesprochen jitterarm ist).
In anderen Worten : mit einem generischen Windowstreiber ist der Computer der Master und das Interface nimmt ein Audiostream vom PC an. Bei DS und MME wird das Signal durch den K-Mixer geschickt und evt. resampled. Bei WASAPI und KS wird der Mixer zwar umgangen, aber die Taktung liegt immer noch beim Windows Betriebssystem.
Dies kann man sehr einfach Überprüfen in dem man bei einem generischen Windowstreiber im Gerätemanager den "Systemzeitgeber" deaktiviert. Dann läuft nix mehr.
Bei ASIO läuft dann noch alles bestens.
ASIO :
Steinbergs ASIO Standard ist eine Normierung wie ein Gerätehersteller seine proprietäre Software an einen Windows Computer auf der HAL-Ebene (Hardwareabstraktionsschicht) programmieren kan
Die Norm sieht auch verschiedene Einhaltungsstandards wie Latenz und Buffers vor, aber ganz grundsätzlich ist die Norm um die Kommunikation mit Windows zu gewähren OHNE damit auf die Windowssoftware zurück zu greifen.
Dafür setzt das ASIO Gerät auf die Hardwareabstraktionsschicht auf und isoliert sich von allen Teilen des Betriebssystems. Dies heisst z.B. dass in einem PC mit einer ASIO Soundkarte/Interface gibt es nun 2 unabhängige Geräte die beide auf der Computerplatine sitzen (entweder über USB, FireWire oder PCI). Dies ist auch im Gerätemanager ausgewiesen.
Weil ein ASIO Gerät auf der HAL via einem Datenbus angedockt ist, kann die Kommunikation zum PC NUR in Datenpakete vorgehen. Da es keine Taktung einer Clock in so einem Modus gibt, wird der Taktgeber zwangsläuffig die Soundkarte/Interface sein.
Also eine asynchrone Taktung !!
Die asynchone USB Audio Class 2, die es über Apple´s CoreAudio und Linux schon lange gibt, ist ein ganz anderes Thema, geehrter Fujak.
Vincent´s "Welltemperedcomputer.com" beleuchtet USB Audio sehr verständlich.
Mit hochachtungsvollen Grüße
Leif