USB - vor und nach dem Player. Eine Diskussion

Bernd Peter
Aktiver Hörer
Beiträge: 3996
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo,

die RME-Geräte kommen ja von der Studiotechnik, da wird entweder mit Wordclock gearbeitet oder asynchron getaktet.

Und asynchron ist dabei nicht nur ein USB-Modus, sondern das Vorhandensein eines gesteuerten Pufferspeichers im Empfänger, aus dem dann mit eigener Clock das Musiksignal getaktet wird.

Das kann Firewire, HDSP(PCI, PCIe) oder USB sein.

Daß man mit Synchronisation auf das Eingangssignal ebenfalls voll dabei sein kann, ist im Forum ja bewiesen worden, wird aber mehr dem HiFi-Bereich zuzurechnen bleiben.

Gruß

Bernd Peter
Bild
Ralf Koschnicke
Aktiver Hersteller
Beiträge: 374
Registriert: 22.07.2008, 11:24
Wohnort: Wöllstein
Kontaktdaten:

Beitrag von Ralf Koschnicke »

Lieber Leif,
Zensur kann ich eigentlich auch keine erkennen …?

Nun um mal vom Hiface wegzukommen – das ist ja kein Hiface-Thread – ein Zitat aus dem Manual zur neuen USB-Karte des Lynx Aurora 8/16:

„We recommend using Internal as the SYNC SOURCE for the best clock performance.
In this state, the Aurora can respond to sample rate changes from audio software...“

Das bedeutet: Der Aurora generiert den Takt mit seiner internen Clock. Über USB erhält er nur die Datenpakete und die Schaltinformation von der Abspielsoftware, auf welche Abtastrate die interne Clock geschaltet wird. Letzteres erspart lediglich lästiges manuelles Umschalten oder Fehlanpassungen. Die Versorgungsspannung bezieht der Wandler auch garantiert nicht über USB (bei dem Strombedarf würde das USB-Kabel ruckzuck wegbrennen).

Damit ist das Ideal eigentlich fast umgesetzt. Das „fast“ füge ich nur ein, weil theoretisch noch die Möglickeit besteht, dass HF-Störungen per USB-Kabel zum Wandler kommen. Dann könnte der Wandler vielleicht doch noch auf Einflüsse vom Rechner reagieren.
Mich würde nun aber sehr wundern, wenn der Rechner noch irgendeinen Einfluss auf den Sound hat.

Grüße
Ralf
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Ralf,

es freut mich, dass du diese asynchrone Möglichkeit ansprichst.
Meine Aurora läuft auch mit einem L-Slot drin, aber jedoch mit FireWire.
Es gibt da ein paar Kleinigkeiten im Bezug zum FW EEE1394 bzw. USB -Controler Chipset die die Bandbreite von USB trüben könnte, aber klar ist, dass hier ein völlig abgetrennter Modus gefahren wird.
Das ist Beispielhaft simpel und konsequent gelöst !

L.
Bild
veloplex
Aktiver Hörer
Beiträge: 360
Registriert: 23.01.2010, 13:41
Wohnort: Berlin

Beitrag von veloplex »

Hallo.

Ulli und Fujak
Fujak hat geschrieben:
Zu Deiner anderen Frage: Ich setze das Hiface vor allem deshalb ein, weil sich klanglich gezeigt hat, dass die Kette PC-USB-Ausgang -> Hiface -> DAC-SPDIF-Eingang weniger Jitter erzeugt als direkt den PC mit dem USB-EIngang des Fireface zu verbinden, auch wenn dies mit einer internen Clock arbeitet. Offenbar wirkt das Hiface (besonders in der Variante mit einer externe PSU) als Jitter-Filter durch die asynchrone Verbindung zwischen PC-USB-Output und Hiface-USB-Input.

Grüße
Fujak
das war die Antwort auf die Frage, die ich eigentlich formulieren wollte und widersprciht doch (wie schon des Öfteren festgestellt) denn theoretischen Überlegungen.
Ralf Koschnicke hat geschrieben:Die Aurora generiert den Takt mit seiner internen Clock. Über USB erhält er nur die Datenpakete und die Schaltinformation von der Abspielsoftware, auf welche Abtastrate die interne Clock geschaltet wird. Letzteres erspart lediglich lästiges manuelles Umschalten oder Fehlanpassungen. Die Versorgungsspannung bezieht der Wandler auch garantiert nicht über USB (bei dem Strombedarf würde das USB-Kabel ruckzuck wegbrennen).

Damit ist das Ideal eigentlich fast umgesetzt.
denn die RME fireface machen das doch ganz ähnlich, soweit ich weis. Nun hast du Fujak empirisch ermittelt, dass diese Variante dem Ideal doch nicht so nahe kommt, wie gedacht. Kann die Überlegung von Ralf
Ralf Koschnicke hat geschrieben: ... dass HF-Störungen per USB-Kabel zum Wandler kommen. Dann könnte der Wandler vielleicht doch noch auf Einflüsse vom Rechner reagieren.
nicht ein Versuch wert sein, es mit einer galvanischen Trennung via USB statt des highface zu versuchen?

Gruß christoph
Bild
gregor
Aktiver Hörer
Beiträge: 669
Registriert: 08.03.2010, 20:08

Beitrag von gregor »

Hallo Christoph,

lt. Herrn Fuchs von RME ist das Fireface UC galvanisch von den 5V USB-Versorgunsspannung getrennt. Auf gearsluts u. a. wird hingegen behauptet, dass das Fireface mit externer Clock zulegen kann. Kann ich in Ermangelung einer solchen nicht testen.

Beste Grüße

gregor
Bild
veloplex
Aktiver Hörer
Beiträge: 360
Registriert: 23.01.2010, 13:41
Wohnort: Berlin

Beitrag von veloplex »

Hallo Gregor,

von der Versorgungsspanung des PC sollte das RME auf jeden Fall getrennt sein. Ich stelle mir eine komplett galvanische Trennung vor um HF-Einstreuungen zu veremeiden, Möglich?

Gruß Christoph
Bild
vincent kars
Aktiver Hörer
Beiträge: 154
Registriert: 15.03.2011, 16:50
Kontaktdaten:

Beitrag von vincent kars »

Jim Lesurf did a nice experiment.
He measured the analog out of a DAC Magic when feed by its own adaptive mode USB and by a asynchronous USB to SPDIF converter (Halide).
http://www.audiomisc.co.uk/Linux/Sound3 ... hange.html
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3996
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo,
Bernd Peter hat geschrieben:Daß man mit Synchronisation auf das Eingangssignal ebenfalls voll dabei sein kann, ist im Forum ja bewiesen worden, wird aber mehr dem HiFi-Bereich zuzurechnen bleiben.
so, jetzt zitiere ich mich selbst, soweit ist es schon.

Nein, was ich sagen wollte ist, daß im HiFi-Bereich in der Regel nur mit 2 Geräten (Quelle,DAC), die jeweils eine eigene Clock haben, gearbeitet wird. Im Studiobereich sind es mehrere Geräte, die über Wordclock arbeiten, aber natürlich auch miteinander synchronisiert werden.

Was die RME Geräte betrifft, hier wird ja bei den Faces die komplette Hardware auf die externen DACs ausgelagert und über die Treibersoftware die Musikdateien vom PC, RME gesteuert, auf den DAC gebracht.

Das ist technisch die optimale Geschichte, da alles im DAC passiert, man kann die Stromversorgung und die Clock im PC eigentlich komplett vergessen.

Aber fujak erklärt, daß dies nicht so ist. Warum wissen wir bisher nicht.

Und nun kommt die Sache mit der HF-Streuung.

Vielleicht kommen wir nun zur Rätsels Lösung.


Gruß

Bernd Peter
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo zusammen,
gregor hat geschrieben:lt. Herrn Fuchs von RME ist das Fireface UC galvanisch von den 5V USB-Versorgunsspannung getrennt. Auf gearsluts u. a. wird hingegen behauptet, dass das Fireface mit externer Clock zulegen kann. Kann ich in Ermangelung einer solchen nicht testen.
das muss kein Widerspruch sein. Denn die galvanische Trennung ist zwar ein wichtiger Faktor aber noch kein Garant dafür, dass eine saubere Wandlung stattfindet.
Mein Hiface, mit dem ich das bessere Ergebnis erziele, hängt beispielsweise immer noch über eine gemeinsame Masse mit dem PC verbunden (was notwendig ist, damit es vom PC erkannt wird).
Und hinsichtlich der externen Clock stellt sich die Frage, um welche Art externer Clock es sich handelt: Wordclock oder eine Konstruktion á la Big Ben, bei der sich das Fireface auf die Clock des Big Ben synchronisiert und von ihm die Audiodaten erhält. In meinen Versuchen, den Big Ben als Wordclock-Geber für das Firefae einzusetzen, war null Unterschied zu hören, in der zweiten Variante als Reclocker hingegen durchaus.

Warum dies so ist, hatte Gert vor längerem erläutert:
Fortepianus hat geschrieben:Ob Du den DAC extern taktest oder intern, macht in diesem Fall qualitativ kaum einen Unterschied. Das Wordclock-Signal, mit dem Du in den DAC gehst, hat z. B. bei CD-Files 44,1kHz. Die Frequenz der Masterclock, die intern verwendet wird, hat aber ein Vielfaches davon, typisch das 256fache, also 11,2896MHz. Diese Frequenz wird lokal im DAC erzeugt und über eine PLL zum externen Wordclocksignal synchron gehalten. Im anderen Fall, bei interner Clock, synchronisiert die Masterclock auf die Daten vom USB-Eingang oder steuert sogar rückwarts die USB-Quelle bei asynchronem USB-Modus. Die verwendete Masterclock ist in beiden Fällen die gleiche, nämlich die des DAC. Läuft das Auslesen der Daten vom USB-Anschluss vom DAC gesteuert, ist ein Synchronisieren auf eine weitere Clock, hier die des Big Ben, eher kontraproduktiv.

Der Big Ben spielt seine saubere Clock dann aus, wenn Du einen S/PDIF-Datenlieferanten hast, der zum DAC geht. Dann wird das zappelige S/PDIF-Eingangssignal im Big Ben neu getaktet und der DAC kann mit erheblich geringerem Jitter seine Masterclock darauf synchronisieren.
Bernd Peter hat geschrieben:Das ist technisch die optimale Geschichte, da alles im DAC passiert, man kann die Stromversorgung und die Clock im PC eigentlich komplett vergessen.

Aber fujak erklärt, daß dies nicht so ist. Warum wissen wir bisher nicht.

Und nun kommt die Sache mit der HF-Streuung.

Vielleicht kommen wir nun zur Rätsels Lösung.
Ja, das ist in der Tat die interessante Frage. Denn genau aufgrund des von Dir nochmal dargestellten RME-Konzeptes des Fireface UC hatte ich es mir damals angeschafft - mit der Hoffnung, damit nun alle Jitter-Sorgen los zu sein.

Wenn eine HF-Einstreuung dafür verantwortlich wäre, stellen sich die Fragen:
Um welche Art von HF-Einstreuung handelt es sich?
Welchen Weg genau nimmt sie?
Und wie genau lässt sie sich vermeiden?

Grüße
Fujak
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 3996
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo,

wenn man ein USB-Netzteil wie das Aqvox vor das USB-Kabel (trotz galvanischer Trennung zum RME-Face) steckt, müsste doch der HF-Müll schon am Netzteil abgeleitet werden.

Denn ansonsten muss der ja irgendwo im RME-Face auf Masse, was dort eigentlich ungünstig ist.

Sehe ich das richtig?

Gruß

Bernd Peter
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Forum,

Ich kann entnehmen, dass jedenfalls Bernd Peter den Vorteil von der externen, DAC gesteuerten Masterclock Modus unterstützt.

Es sollte aber dabei klar sein, dass nicht nur das Prinzip einer solchen asynchronen Verbindung, aber natürlich auch die ultimative Qualität dieser Clock. Sonst hat das kein Vorteil. Im Bereich von Clocks gibt es gewaltige Unterschiede, und einzelne Clocks können allein als Bauteil mehrere hundert Euro kosten. Ein Wandlerchip ist hingegen ein relativ simples Teil (Preis im Großhandel 40-150 Cent), dessen Performance hochgradig abhängig ist von stabilem Strom und eine präzise Clock.
Fujak hat geschrieben:Ja, das ist in der Tat die interessante Frage. Denn genau aufgrund des von Dir nochmal dargestellten RME-Konzeptes des Fireface UC hatte ich es mir damals angeschafft - mit der Hoffnung, damit nun alle Jitter-Sorgen los zu sein.
... das würde ich auch so sehen, lieber Fujak, aber deine praktische Erfahrung zeigt ja dass dein BigBen hörbar mehr Jitter reinigt als das FireFace in diesem asynchronen Modus. Dafür gibt es, glaube ich, zwei potenzielle Gründe:

Entweder ist das Syncro-Lock PLL nicht im Stande den Jitter zu unterdrücken (unwahrscheinlich), oder die eingebaute Clock der RME ist der Clock des BigBen entschieden unterlegen (eher wahrscheinlich).

Jedoch habe ich auch das Gefühl, dass du der RME nicht optimale Bedingungen geboten hast, denn obwohl dein Netbook prinzipiell eine Bit-Perfekte Ausgabe erlaubt, so hat RME selber eine "Warnung" gegen Intel Atom ausgesprochen:
RME hat geschrieben:USB 2.0 ist auf Wintel-Rechnern schon seit circa 2002 zu finden, hat aber in den ersten Generationen des USB Controllers nicht so funktioniert wie es für Echtzeitaudio notwendig wäre. Auch wenn Rechner aus dem Jahre 2003 (z.B. Intel 875 mit P4 Prozessor) prinzipiell mit dem Fireface UC funktionieren, verursacht schon eine simple Stereo-Wiedergabe eine CPU-Last von 30%. Latenzen unter 256 Samples sind selbst in einer Minimalanwendung nicht immer knacksfrei. Bei genauerer Untersuchung stellt sich heraus, dass die CPU-Last im Grunde eine versteckte DPC-Last ist. Offensichtlich arbeitet der Interfacechip ineffizient, und zwingt dem Rechner (der CPU) Wartepausen auf.

Dieses Verhalten ist Treiber- und Betriebssystem-unabhängig. Erst mit dem ICH7 scheint Intel das Problem erkannt zu haben. Moderne Rechner mit ICH8, 9 und 10 weisen prinzipiell eine hervorragende USB-Performance auf, kommen dann aber auch meist mit einem Core 2 Duo Prozessor daher, so dass zusätzlich auch eine hohe Rechenleistung zur Verfügung steht. Aktuelle Netbooks sind oft mit ICH7 bestückt, daher prinzipiell kompatibel. Der schmalbrüstige Atom-Prozessor führt dann doch wieder zu einer recht hohen Belastung bei simpler Wiedergabe, was aber teilweise auch auf die integrierte Soundkarte zutrifft. Ältere AMD- und ATI-basierte Rechner besitzen oft katastrophale USB-Interfaces, die sich in der Praxis als vollständig inkompatibel zum Fireface UC erweisen.

Auf Basis der obigen Erkenntnisse, und um Enttäuschungen auf Seiten unserer Kunden zu vermeiden, wurden die Systemvoraussetzungen zum Betrieb des Fireface UC streng auf mindestens Core 2 Duo CPU festgelegt. Diese kommt immer zusammen mit neueren USB-Controllern. Ältere Rechner funktionieren durchaus, siehe Liste, aber eben mit Einschänkungen. Ob diese im Einzelfall akzeptabel sind kann nur der Kunde selbst entscheiden.

Vereinfacht gesagt: das Fireface UC ist ein Produkt des Jahres 2009, top-aktuell, und läuft am besten mit ebensolchen Computern.

Als Betriebssystem arbeitet alles oberhalb Windows XP SP2, welches eine verbesserte USB-Unterstützung enthielt. Auf dem Mac wird OS X 10.5 gefordert, da das Fireface UC einige Funktionen benutzt, die es vor 10.5 noch nicht gab.

Doch selbst der neueste Rechner kann versagen, wenn er schlecht konfiguriert ist. Dies trifft vor allem auf Notebooks zu, die manchmal schon ab Werk schlecht funktionieren, und sich ohne spezielle Treiber- oder BIOS-Updates nicht signifikant verbessern lassen. Dies betrifft aber nicht nur das Fireface UC, sondern jegliches Audio-Interface.
Eine solche Problematik ist ein Jitter-Multiplikator.

Ich will wirklich nicht das Thema Schnittstellen und Datenverarbeitung auf die Spitze treiben, aber im Umgang mit Computer Audio sind dies sehr wichtige Vorraussetzungen um Echtzeit und Jitter in den Griff zu bekommen.

Übrigens sind die alle RME Interfaces auch galvanisch isoliert. Wenn extern gewandelt wird und die sensible Clock extern isoliert ist, ist HF kein wirkliches Problem.

Gruß Leif
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo Leif,

an dieser Front kann ich Entwarnung geben - aus zweierlei Gründen:
der Hintergrund der Mindestanforderungen an die CPU hat vor allem damit zu tun, dass es neben dem Betrieb als Wandler noch ein ganze Reihe weiterer Funktionen gibt (DSP-Mixing, MIDI etc.), die richtig Leistung fordern, vor allem wenn niedrige Latenzen gefordert sind. Die CPU des Netbooks gerät auch nicht ins Schwitzen - das beginnt erst bei 192/24bit.

Zum anderen ändert sich nichts am klanglichen Unterschied mit und ohne Big Ben, wenn ich meinen Office-PC als Abspieler einsetze, der einen DualCore der neuesten Generation beherbergt.

Wenn es eine Jitter-Abhängigkeit von der Leistungsfähigkeit der CPU gäbe, wäre das ja auch ein Hinweis darauf, dass es sich nicht um eine asynchrone Anbindung handeln würde.

Viel eher halte ich die Clock des Fireface als Ursache für den Unterschied. Denn mit Big Ben synchronisiert sich die Fireface-Clock auf die Clock des Big Ben. Egal wie präzise oder unpräzise die Fireface-Clock läuft, es macht dann keinen Unterschied mehr. Ein weiteres Indiz für die Clock als Ursache ist auch die klangliche Steigerung mit einer externen sauberen Stromversorgung, die offenbar der Clock gut bekommt.

Genau das sind die Hintergründe, weswegen ich immer wieder betone, dass Features wie interne Clock oder asynchrone Verbindung zunächst einmal noch nicht viel über das klangliche Resultat aussagt.

Grüße
Fujak
Bild
Ralf Koschnicke
Aktiver Hersteller
Beiträge: 374
Registriert: 22.07.2008, 11:24
Wohnort: Wöllstein
Kontaktdaten:

Beitrag von Ralf Koschnicke »

play-mate hat geschrieben: Ich kann entnehmen, dass jedenfalls Bernd Peter den Vorteil von der externen, DAC gesteuerten Masterclock Modus unterstützt.
Ich glaube das bezweifelt niemand, oder?
play-mate hat geschrieben: Übrigens sind die alle RME Interfaces auch galvanisch isoliert. Wenn extern gewandelt wird und die sensible Clock extern isoliert ist, ist HF kein wirkliches Problem.
Einspruch: Ja, galvanisch isoliert sind die RME-Schnittstellen. So handgewickelt die Trafos bei RME aussehen, so ist wohl aber auch deren Qualität. Ich hatte zwar mit großem Entsetzen feststellen müssen, dass sich das teure Pyramix die Übertrager schenkt (das ist eigentlich ein Skandal für einen ProAudio-Hersteller). Dennoch muss man MERGING zu Gute halten, dass deren Karten ohne Übertrager bessere Ergebnisse liefern als RME mit bzw. meine externen Trennübertrager an den AES32-Karten von RME einen größeren Effekt haben als beim Pyramix.

Ich halte große Stücke auf RME, aber es gibt so manche Einschränkungen. Für die RME-Clock würde ich das auch sagen. Meiner Meinung nach ist die ordentlich aber ganz gewiss keine Referenz. Auch die PCI-Karten haben diese „SteadyClock“. Die Karten lasse ich nur auch bei Wiedergabe immer vom AD via AES/EBU takten, wodurch der DA dann auf dem Takt vom AD hängt und nicht an der „SteadyClock“. Schalte ich bei laufender Wiedergabe dann den AD aus, springt die Karte sofort lückenlos auf intern um. Das hört man jedoch gewaltig. Also für die o.g. Klangunterschiede würde ich zuerst mal die Clock des Big Ben verantwortlich machen. Das Ding ist einfach verdammt gut … zeigt sich immer wieder.

Noch eine Klarstellung zur galvanischen Trennung, weil nun ein paar Mal Fragen auftauchten: Nun ganz präzise die Mechanismen erklären kann ich auch nicht, aber es geht primär um HF-Noise, welches über die Datenleitung kommt. Was ich hier ins Spiel bringen wollte, war HF-Noise über die Datenleitung. Und dabei ist ja auch das Datensignal selbst aus Sicht der Analogseite HF-Noise. Ich glaube das ist der Hauptgrund, warum Crystal in dem alten Datenblatt darauf hinweist. Da habe ich ein Signal mit über 100MHz Bandbreite in meinem Wandler. Das ist HF und das nimmt gerne Mal Wege, die man nicht so gut kontrollieren kann.

Grüße
Ralf
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

hallo Fujak,

Vorerst muss ich betonen dass ich hier keine direkte Front an dein Set-Up führe, aber das ich denke dass es eine allgemeine Gültigkeit hat, die potentielle Probleme mit USB oder andere Schnittstellen zu diskutieren.

Das zitierte RME Statement bezieht sich aber nicht nur auf die CPU Last, aber auf den USB Chipset Controller. Abgesehen von dem 1000 Hz Polling das mitten im sensibelsten Hörbereich liegt, so gibt es so manche andere Störfaktoren in diesem Chipset.

In der AA Diskussion hat sich John Swenson (Logitech/Squeezebox) eine interessante und relevante Aussage getätigt :
John Swenson hat geschrieben:The interesting aspect of this noise is that if you look at the spectrum of it you see a strong 1KHz component, which is the packet rate on the USB bus. This falls right smack dab in the middle of the audio range. It gets even worse. In most circumstances the exact time at which packets are sent is controlled by software, NOT a low jitter hardware clock. This means that things like kernel scheduling policies, interrupt latencies etc have a HUGE impact on the exact timing of those packets. It comes out to close to 1KHz all the time, but there is significant variations on the exact time between packets. This causes that 1KHz component of the ground spectrum to spread out, it has "skirts". This "modulation" is in the low end of the audio range. There is a fair amount of evidence that this type of low frequency jitter can make subtle changes in the listening experience even when it is fairly low level.
- hier liegen sicherlich einige vermutete HF Probleme.

Natürlich wollen Hersteller die Nachfrage von Konsumenten eine USB Schnittstelle zu Verfügung zu stellen befriedigen, aber das bedeutet nicht Zwangsweise dass USB eine Problemlose High-End Audio Schnittstelle ist.

Lynx hat mehrfach darauf hingewiesen, dass sogar bei FireWire die technische Begrenzung nicht am Gerät liegt sondern im Controller Chip. (Lynx hat sogar Konsequenzen gezogen....)

Gruß Leif
Bild
play-mate
Aktiver Hörer
Beiträge: 448
Registriert: 26.02.2010, 08:18
Wohnort: Berlin

Beitrag von play-mate »

Hallo Ralf

Vielen dank auf den Verweis auf die Problematik mit den Übertragern und deren galvanischer Trennung. Ich hatte den Eindruck dass solche Fragen endgültig von modernen Geräten gelöst seien.... :shock:
-speziell im Studiobereich.
(kann man wirklich Merging mit RME vergleichen ?)

Wie setzt du deine Trennübertrager ein ? Magst du dies mal erläutern ?

Ich habe auf längerer Sicht, übrigens auch vor mein FireWire gegen eine PCIe Lösung zu wechseln...Mal sehen, die Merging sind mir ein wenig kostbar und DSD brauche ich wohl nicht :cheers:


Leif
Bild
Antworten