Digitale Schnittstellen Einfach, Teil 2: FireWire

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

Digitale Schnittstellen Einfach, Teil 2: FireWire

Beitrag von play-mate »

Geehrtes Forum,

Zu einer weiteren Folge von digitalen Schnittstellen geht´s um FireWire.
Vorab ist meine These (immer noch) dass digitale Schnittstellen, eine zeitliche Verzerrung (Jitter) mit sich führen und daher auch unterschiedlich klingen.

Es scheint immer noch nicht Konsens zu sein, dass Jitter der absolute Grund für klangliche Unterschiede ist, aber vorausgesetzt dass alle Bits und Bytes übertragen werden, ist der einstige Faktor der übrig bleibt der Jitter.

Klar ist dass Netzwerkplayer per se erheblich weniger Jitter produzieren als Computer, aber im richtigen Verbund und mit der richtigen Schnittstellen-Technik, kann ein Computersystem genau so Jitterarm werden wie der beste Netzwerkplayer (oder sogar besser).

Es gilt die richtige Übertragung des Clocksignals zu gewähren, denn der Jitter des Computers kann somit völlig isoliert werden.
Einer dieser Techniken ist FireWire ( USB kann ähnlich funktionieren)

FireWire Schnittstellen sieht man z.B. nicht in Netzwerkplayern, (meist) weil diese Technik spezifische Treiber benötigt um die Clock des D/A Wandlers an das Signal des Zuspielers (Computer) zu koppeln.
-dabei wird DAC und Playersoftware ein Verbund eingehen wo nur die Clock des Wandlers die Präzision vorgibt.
Der Computer liefert dabei allein die Datenpakete, aber hat keine eigene Taktung mehr.
Diesen Verbund (Master/Slave) nennt man eine asynchrone Übertragung, denn Taktsignal und Daten sind physisch von einander getrennt. So mit gewährt man dass nur eine Clock (die des DACs) den gesamten Kreislauf taktet, und dass der Jitter des Computers überhaupt keinen Einfluss mehr hat.

Leider ist es so, dass um einen solchen Verbund (mit FireWire oder USB) mit einem Zuspieler herzustellen, muss der Hersteller des DACs einen Treiber entwickeln der den Zuspieler instruiert wie die Kommunikation zu laufen hat. Solche Treiberentwicklung kostet ein Haufen Aufwand und verursacht hohe Kosten die die DAC Hersteller scheuen. Daher ist diese Technik auch nicht weit verbreitet, denn sie lässt sich nur mit einem Computer realisieren.

Der Vorteil jedoch ist dass die Flexibilität eines Computers mit der Takt-Genauigkeit des DACs verschmolzen wird. Dabei kann man z.B. Acourate und/oder digitale Frequenzweichen direkt ins DSP der Playersoftware (Foobar, J.River, cPlay etc.) integrieren und sich darauf verlassen dass der Jitter des Computer kein Thema ist.
Getaktet wird nämlich nur im DAC !

Implizit wird (hoffentlich) auch deutlicher warum digitale Geräte nicht einfach an einander gekoppelt werden können, ohne Qualitätsverlust (und warum kluge Hersteller Wandler und Player integrieren). Der Knackpunkt ist : nur einen Taktgeber im System.
Bild
nihil.sine.causa
Aktiver Hörer
Beiträge: 1506
Registriert: 28.07.2011, 12:31
Wohnort: Bonn

Beitrag von nihil.sine.causa »

Hallo Leif,

die hier beschriebene Strategie, der asynchronen Übertragung verfolge ich bei meiner Kette auch (wenngleich es nicht FireWire sondern USB ist; M2TECH Young). Beim reinen Musikhören macht mir eine kleine zeitliche Verzögerung nichts aus.
play-mate hat geschrieben: Leider ist es so, dass um einen solchen Verbund (mit FireWire oder USB) mit einem Zuspieler herzustellen, muss der Hersteller des DACs einen Treiber entwickeln der den Zuspieler instruiert wie die Kommunikation zu laufen hat. Solche Treiberentwicklung kostet ein Haufen Aufwand und verursacht hohe Kosten die die DAC Hersteller scheuen. Daher ist diese Technik auch nicht weit verbreitet, denn sie lässt sich nur mit einem Computer realisieren.
Damit sind die Treiber proprietär, d.h. ihre Eigenschaften werden im Wesentlichen vom jeweiligen Hersteller bestimmt. Über die Qualität von Wandlern habe ich schon vieles gefunden. Es würde mich aber vor allem auch interessieren, was hinsichtlich der Qualität dieser Treiber von unterschiedlichen Herstellern bekannt ist.

Gruß
Harald
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

9.0 CONCLUSION
Digital audio interfacing using IEEE1394 is possible. Sample clock synchronisation
information transmitter over the same interface will have levels of jitter that will not be
acceptable for high quality applications without high levels of attenuation in clock
recovery systems.
There are several engineering solutions to the problem. These need to be
addressed for the “Specification For The Transmission Of Audio And Music Data”
over IEEE1394, IEC-PAS 61883-6, to be able to support high quality audio
transmission.
aus "Sample clock jitter and real-time audio over the IEEE1394 high performance serial bus." von Julian Dunn

Gruss, Uli
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Eine weitere Literaturrecherche führt zu einem interessanten Begriff: JetPLL. Es zeigt sich dass es eine Reihe von Soundkarten gibt, welche die patentierte Technlogie verwenden. Inklusive Firewire-Karten, z.B. Presonus Firewire. Auch hier ist das Ziel, den digitalen Audiodatenverkehr nachträglich zu entjittern.

Natürlich gibt es einen Artikel dazu, welche das Prinzip und die Vorteile vergleicht. Interessant, wie doch immer wieder dieselben Namen auftauchen, wenn man sich näher mit Jitter befasst.
Siehe also z.B. http://www.tcelectronic.com/media/frand ... _tc(1).pdf, worin der DICEII-Chip und die integrierte JetPLL beschrieben wird. u.a. mit dem Ziel, den bei Firewire möglichen Jitter von 20 bis 40 ns RMS um mindestens 60 dB ab 200 Hz aufwärts zu reduzieren.

Zum DICEII gibt es hier etwas, http://www.profusionplc.com/pro/gex/pca ... I-TCD2200K
Vielleicht macht Gert mal was draus? :D

Also denn, wer hat evtl. schon Erfahrungen damit? Welche DACs oder Soundkarten verwenden den DICEII ?

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

Beitrag von play-mate »

Hallo Uli,

Es ist nicht von der Hand zu weisen, dass FireWire (genau so wie USB) eine noch kompliziertere Sache als sich die meisten sich vorstellen.
Der Artikel von Julian Dunn konkludiert aber keines Falls :
Sample clock synchronisation information transmitter over the same interface will have levels of jitter that will not be acceptable for high quality applications without high levels of attenuation in clock
recovery systems.
-das hast du falsch verstanden.
Dies ist die "These" (der Ausgangspunkt) der Untersuchung.
Mr. Dunn erläutert nämlich das, je nach Protokoll ist die Zuweisung der Sampleclock in der Hand des Transmitters oder des Recievers. Dies ist auch analog zu den Unterschieden von adaptiven und asynchronen USB Transfer Modi.

USB und FireWire sind ja Schnittstellen die in beide Richtungen kommunizieren können, wobei wir uns im Playback nur für die eine interessieren. Es gilt also das richtige Protokoll zu wählen : den IEC 61883-1
Hier heisst es :
8.4.5 For applications with only one destination and with a source, such as a playback device, that can have it’s transmission rate manipulated the destination receiver could control the synchronisation
-dies ist der entscheidende Punkt !
FireWire kann im DAC synchronisiert werden, muss aber nicht. In hochwertigem Audio ist dies aber meist immer so.
Falls du mich in dieser Sache herausfordern willst, können wir dies argumentativ klären.
Ich denke nur nicht hier im Forum.... :cheers:
(-das wird zu technisch und zu langweilig)

Der TC DICE Chip sieht sehr interessant aus (danke für den Hinweiss).

Unterschiedliche FireWire / USB Controller haben durchaus verschiedene Performance und damit vermutlich auch ungleiche Klangeigenschaften. Im Promillebereich.....
Der Texas Instruments TSB43AB23 Chip gilt in Tonstudios als empfehlenswert für Audio.


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

Beitrag von play-mate »

Hallo Harald

Wie du richtig erwähnst ist der Softwaretreiber für deinen DAC proprietär. Das ist gut so, denn nur dann passt sich der DAC sich spezifisch an das jeweilige Betriebsystem optimal an.
Aber Treibersoftware ist selten in der Hand von Herstellern im Hifi-Bereich. So was wird meist bei spezialisierten Firmen entwickelt, und genau dies kostet richtig viel Geld.
Daher begnügen sich viele Hersteller damit den DAC an ein Betriebsystem und vorhandene Protokolle anzupassen, statt umgekehrt.

In den Jahren wo ich verschiedene Updates von Treibersoftware an der selben Hardware verfolgt habe, kann ich jedenfalls bezeugen dass Software ein wichtigen Einfluss auf Audioqualität hat.
Firmen wie RME, Lynx etc. haben eigene Softwareabteilungen, und dort werden Fortschritte & Entwicklungen in Form von Updates von Treibern, auch an Kunden weitergegeben.

Gruß Leif
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Leif,

ich hab das schon verinnerlicht, dass ich immer alles falsch verstehe. :oops:

Nur wenn ich dann lese
Network-based digital audio interfaces are becoming increasingly popular. But they do pose a significant jitter problem wherever high-quality conversion to/from analog is required. This is true even with networks such as 1394 that provide dedicated support for isochronous flows. Conventional PLL solutions have too little jitter attenuation, too much intrinsic jitter, and/or too narrow a frequency range. More advanced solutions tend to have too high a cost. A new clocking technology that boasts high performance and low cost is presented. It has been implemented in a recent audio-over-1394 chip.
und
The resulting jitter in the 1394 clock reference signal is calculated to 20 to 40 ns RMS and it is recommended by [11] to reduce this by at least 60 dB from 200 Hz and up.
so wie in dem zitierten Clean-Clocks-Artikel, dann weiss ich ja immer noch nicht, was denn nun z.B. meine RME Fireface genau tut. Oder was sie nicht tut. Kannst Du mir das bitte erklären?

Ergo wäre es IMHO zu einfach, Firewire als DIE Lösung im Vergleich zu spdif zu sehen.

Ich hab ja schon geschrieben, dass mir in dem Zusammenhang immer dieselben Namen auffallen. Chris Travis beim Artikel Clean Clock und dem DICEII-Chip, er wiederum zusammen mit Paul Lesso in einem AES-Artikel "Specifying the Jitter Performance of Audio Components", wo man sich um saubere Definitionen bemüht, wobei Lesso ja als Mitarbeiter bei Wolfson am spdif-Empfänger WM8804 mitgestrickt hat. Über allem schwebt immer der Name Dunn.

Und ich wollte da mit meinen Beiträgen schlicht auf all das hinweisen. Erklären tu ich das nun nicht, hab es sowieso nicht verstanden :mrgreen:

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

Beitrag von play-mate »

Hallo Uli,

Es ist nicht mein das Anliegen die verschiedenen Schnittstellen absolut zu bewerten. Alle digitalen Schnittstellen haben Jitter, aber es fragt sich natürlich immer, welches das beste ist.....
-so etwas ist immer : Relativ :mrgreen:

Ich wollte keineswegs behaupten dass du alles falsch verstehst. Im Gegenteil : Du bist mein bester Kritiker :cheers:

Es ist meine feste Überzeugung dass wir im digitalen Domain niemals Jitter so richtig loswerden, und dass wir für Jitter nur verschiedene Möglichkeiten haben um ihn irgendwie zu reduzieren.
Schnittstellen und die Façon wie digitale Geräte kommunizieren ist der Knackpunkt. Deshalb auch diese Serie.

Im Gegensatz zu analogen Geräten ist es nicht einfach die einzelnen Komponenten mit einander zu verbinden (natürlich unter Rücksicht von Kabel, Impedanzen, Schirmung, Kapazität etc.), denn um Jitter zu Kontrollieren muss genausten ge-taktet werden. Wenn aber zwei (oder gar 3-4) Geräte nicht den selben Takt haben, kommt es zu mehr Jitter.
(-dies ist nicht von der Hand zu weisen)

Je mehr man von Jitter verstanden hat, desto mehr versteht man, dass man noch gar nichts verstanden hat ! :?

Kein Wunder dass es so viele Kontroversen gibt.

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

Beitrag von vincent kars »

Firewire and USB have a couple of things in common
• Both are capable of bit perfect transmission
• Both can induce input jitter
• Both can be used in adaptive and asynchronous mode.

The big difference is that all major OS (Win, OSX, Linux) do have a native mode USB audio class 1 driver. (OSX and Linux also support class 2).
There is no such standard for Firewire.

As a consequence all a USB DAC manufacturer has to do is buying a receiver chip.
In case of Firewire he also has to take care of the driver at the PC side (or licenses it)
This explains why there are so many USB audio devices and so few Firewire DACs.

Almost all Firewire DACs use adaptive mode just like most USB counterparts.
The TC Audio DICE chip has a good reputation for input jitter reduction but is not asynchronous.
Metric Halo is the only one known to me having an Async Firewire setup.
Bild
nihil.sine.causa
Aktiver Hörer
Beiträge: 1506
Registriert: 28.07.2011, 12:31
Wohnort: Bonn

Beitrag von nihil.sine.causa »

Hallo zusammen,

Alle hier im Forum haben das gemeinsame Ziel der Optimierung. Im Zusammenhang mit der Schnittstellendiskussion stellen sich mir (naiv) folgende Fragen:

1. Was ist in der Praxis die bessere Variante S/PDIF oder FireWire bzw. USB? Habt Ihr hierzu schon einmal Vergleiche gefahren unter analogen Bedingungen (PC als Quelle, identischer Wandler, ähnliche Kette etc.)?

2. Gesetzt wir bleiben mal bei der FireWire / USB Lösung. Es gibt doch sicher Hersteller in diesem Markt, die den Aufwand nicht scheuen, eine hervorragende Lösung zu entwickeln. Gibt es irgendwo einen direkten Vergleich der einzelnen Treiber (dann schon auch unter Variation der Wandler)?

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

Beitrag von vincent kars »

What is “Praxis”?
The problem is we don’t hear SPDIF, AES/EBU, USB adaptive, USB async, Firewire but always the implementation. That is praxis.
All these implementations varies in quality.
DACs with both Firewire and USB are rare.
Lots of DACs with SPDIF and USB.
Most of the time a very cheap 16/48 adaptive mode USB implementation.
Based on hanging around too long and too often on too many audio forums I have the impression that people often prefer the SPDIF.
A nice example (DagMagic) can found here: http://thewelltemperedcomputer.com/KB/USB.html

But there are DACs like Ayre QB9 (async USB only) measuring perfect on jitter.
As there are so many parameters, a direct comparison is hard.

SPDIF makes matters also pretty complex. What is the jitter of the source? Sure makes a difference.
Etc. etc.
Bild
Herbert Z
Aktiver Hörer
Beiträge: 664
Registriert: 25.08.2008, 02:45
Wohnort: Houston, Texas (USA)

Beitrag von Herbert Z »

play-mate hat geschrieben:
Implizit wird (hoffentlich) auch deutlicher warum digitale Geräte nicht einfach an einander gekoppelt werden können, ohne Qualitätsverlust (und warum kluge Hersteller Wandler und Player integrieren). Der Knackpunkt ist : nur einen Taktgeber im System.
Hallo,

das ist nicht uneigeschraenkt so. Die Spitzengeraete von Accuphase und Esoteric sind Laufwerk - Wandler Kombinationen (mit einer Uebertragungs-schnittstellen)

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

Beitrag von play-mate »

Hallo Vincent,
Metric Halo is the only one known to me having an Async Firewire setup.
....async FireWire ist mehr die Regel als die Ausnahme. Weiss DAC 202, Lynx Aurora, Prism Orpheus sind alle "async" (in Wirklichkeit heisst es isochronous)

Alle diese DACs sind mit eigenen Treiber ausgestattet.

Daniel Weiss sagt
Why Firewire?

Firewire is a peer-to-peer protocol, meaning that every device on a Firewire network is equally capable of talking to every other device. Two video cameras on a Firewire network can share data with each other. A Firewire audio interface could save sound data directly to a Firewire hard drive. Your computer is just another peer on this network, and has no inherent special status.

Firewire is always implemented in hardware, with a special controller chip on every device. So the load it puts on your CPU is much lighter than USB communications load, and you're much less likely to lose any sound data just because you're running fifteen things at once. Specialized hardware usually makes things faster and more reliable, and this is one of those times.

But the real reason Firewire is more reliable than USB is more fundamental than that. It's because Firewire allows two operating modes. One is asynchronous, similar to what USB uses. The other is isochronous mode, and it lets a device carve out a certain dedicated amount of bandwidth that other devices can't touch. It gets a certain number of time slices each second all its own. The advantages for audio should be obvious: that stream of data can just keep on flowing, and as long as there isn't more bandwidth demand than the wire can handle (not very likely) nothing will interfere with it. No collisions, no glitches.

From a practical perspective, this also makes it safer to send a lot more audio via Firewire. That's why most of the multichannel interfaces (16 channels, 24 channels, etc.) are Firewire devices, and USB devices usually just send a two-channel stereo signal.

For hooking up your mouse, keyboard or thumb drive, USB is plenty fast and plenty cheap. For hard drives, either one will do (although Firewire is somewhat more reliable). For audio devices, USB will do fine if no other devices are competing with it and if you have processor room to spare. But Firewire will always be able to handle more load with lower latency and no glitches, because it has resources it can set aside to make sure your audio gets where it needs to go.



-und noch ein Zitat. Diesmal von Bob Katz :
Digital interfaces do not contribute to audible problems UNLESS they
are driving the clocks which are driving the converters. This isn't
even possible in the case of Firewire since Firewire is clockless
(asynchronous). So if you think about it, Firewire is potentially even
better than SPDIF since it invites a circuit design with a master clock
in it. In the next edition of my book I'm going to stress the use of
the two terms "Synchronous interface" and "Asynchronous
interface". One difference between Firewire, SCSI, or Ethernet, for
example, versus SPDIF, AES/EBU, or MADI, for example, is that the
former three are Asynchronous, and the latter three are Synchronous. A
Synchronous interface contains an imbedded clock or works with a clock.
An asynchronous interface has no clock in it at all. So in reality,
there is NO JITTER to measure in the asynchronous interface; it's
impossible to measure or even have the concept of jitter. All it is
carrying is data. The data gets to the next place in line just fine.
Jitter only would happen or be measurable when the data is clocked out
at the other side. And even then it is not relevant unless that clock
is used to drive a converter. In a Firewire situation, as long as the
converters are being driven by a stable clock, then you have nothing to
worry about re jitter.
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo Leif,

die Frage, ob adaptiver Modus oder isochroner Modus mit asynchronen Endpunkten (um mal die korrekten Bezeichnungen zu verwenden), ist in der Praxis zunächst nur ein theoretischer Unterschied. Vincent hat aus meiner Sicht den entscheidenden Aspekt thematisiert:

Weder die Art der Schnittstelle (USB/SPDIF/Firewire/...) noch die Art der Übertragung (adaptiv/isochron mit async. Endpunkten) entscheidet in der Praxis, sondern in erster Linie die Qualität der Umsetzung/Implementierung. Ich führe aus meiner eigenen Erfahrung immer wieder gerne die Beispiele Emu und Musiland an, die beide USB-DAC-Interfaces mit asynchronem Modus für "Low Jitter" anbieten. Beide schneiden aber klanglich nicht so gut ab, wie bessere USB-DACs mit adaptivem Modus, der dafür aber hochwertig ausgeführt wird (z.B. Benchmark DAC-1).

Auch das von vielen (auch mir) so geschätzte Hiface als USB-SPDIF-Konverter arbeitet mit eigenen Clocks asynchron und klingt von allen derartigen Umsetzern, die ich bislang gehört habe, mit am besten. Doch schaut man sich das Innenleben an, so entdeckt man eine Reihe Schwachpunkte, die einen großen Teil des theoretischen Vorteils wieder aufzehren, z.B. die Stromversorgung über den USB-Bus des PC, SPDIF-Übertrager etc. - Hier im Forum gibt es einige Berichte (u.a. von Ulli "modmix" und auch mir), die zeigen, was man klanglich aus so einem kleinen Kerlchen noch herausholen kann, wenn diese klanglichen Engpässe beseitigt werden.

Eine Erörterung der Schnittstellen und deren Übetragungsprotokolle kann also bestenfalls einiges über die technische Funktionsweise sowie deren theoretische Vorzüge deutlich machen, das klangliche Resultat aber wird letztlich an anderer Stelle entschieden.

Grüße
Fujak
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Wenn man bezgl. Jitter recherchiert, dann trifft man früher oder später auf die bereits genannten Koniferen und die von ihnen mit entwickelten Schaltungen, also JetPLL bei DICE im Fall von Firewire. Oder dem Wolfson WM8804 spdif Receiver (Parallelthread Teil 1).

Es ist dann spannend, z.B. im Zusammenhang mit dem WM8804 ein Dokument zu lesen, welches weitere Erforderlichkeiten aufzählt. Was genau den Erfahrungen beipflichtet, die Fujak beigesteuert hat.
Siehe also z.B. http://www.teddypardo.com/Articles/TeddyDAC.pdf
Vielleicht kann auch Vincent noch etwas dazu beitragen ?

Grüsse, Uli

PS @ Fujak: schau Dir doch auch mal http://teddypardo.com/Resources/SuperTeddyReg.html bzw. http://teddypardo.com/Products/Power%20 ... plies.html an. Wäre da was dabei,was das PeakTech übertreffen könnte?
Bild
Antworten