Mikrocontroller.net - Benutzerbeiträge [de]

MIDI

2016-12-07T21:09:06Z

87.178.118.118: /* Beiträge auf Mikrocontroller */ links

MIDI ('''M'''usical '''I'''nstruments '''D'''igital '''I'''nterface) ist ein Protokoll zum Übertragen von Steuerbefehlen zwischen elektronischen Musikinstrumenten wie Keyboards, Synthesizern, Samplern etc. und auch dem PC.

Das Protokoll ist von der verwendeteten physikalischen Verbindung abhängig. In der ursprünglichen Version werden die Daten [[seriell]] mit 31250 [[Baud]] über eine Stromschleife mit 5 mA übertragen. Zur Vermeidung von Masseschleifen ist die Empfängerseite durch einen Hochgeschwindigkeits-[[Optokoppler]] (z.B. H11L1, 6N138) galvanisch vom Sender getrennt.
Das Protokoll kann damit von allen gängigen [[UART]]s generiert werden.

== Hardware ==
Die Hardware-Spezifikation ist frei verfügbar<ref name="ElSpec">[https://www.midi.org/specifications/item/midi-din-electrical-specification MIDI DIN Electrical Specification]</ref>; die eigentliche MIDI-Spezifikation inzwischen auch<ref>[https://www.midi.org/specifications/item/the-midi-1-0-specification The Complete MIDI 1.0 Detailed Specification]</ref>.

=== Stecker ===
MIDI benutzt fünfpolige DIN-Stecker, bei denen allerdings nur drei Pins belegt sind. Pins 4 und 5 übertragen das Signal, als Hin- und Rückleitung der Stromschleife; Pin 2 dient nur zur Abschirmung des Kabels.

=== Beschaltung ===
Im Ruhezustand ist Pin 5 beim Sender offen, was als logisch "1" gilt; zur Erzeugung einer logischen "0" muss er Pin 5 auf Masse schalten:

[[Bild:MIDI-Sender.svg]]

Die Widerstände begrenzen den Strom, sowohl für den normalen Betrieb, als auch im Falle eines Kurzschlusses (in diesem Fall muss R2 gut 100 mA vertragen). Wenn nur eine 5V-Spannungsversorgung zur Verfügung steht, müssen R1 und R2 durch jeweils 220 Ω ersetzt werden.

Wenn der TXD-Pin des Mikrocontrollers nicht als Open-Drain konfiguriert werden kann, müssen die I/O-Spannung des Mikrocontrollers und die Versorgungsspannung an R2 übereinstimmen. Wenn der TXD-Pin die gut 5 mA Strom nicht verträgt, muss das Signal durch einen Puffer (z.B. (SN)74LVC1G07/NL17SZ07/TC7SZ07) zwischen TXD und R1 verstärkt werden.

Der Empfänger muss den Strom, der zwischen Pins 4 und 5 fließt, auswerten.
Zur Vermeidung eine Masseschleife darf Pin 2 nicht direkt mit der Masse des
Empfängers verbunden werden:

[[Bild:MIDI-Empfänger.svg]]

VCC ist 3,3 V oder 5 V.
R1 dient zur Strombegrenzung.
D1 schützt die LED des Optokopplers vor einer zu hohen Rückwärtsspannung.

Andere häufig verwendete Optokoppler sind 6N137 oder 6N138, die allerdings eine
Versorgungsspannung von 5 V voraussetzen:

[[Bild:MIDI-Empfänger-6N137.svg]] [[Bild:MIDI-Empfänger-6N138.svg]]

Zur Verbesserung der EMI/EMC-Eigenschaften kann es notwendig sein, zusätzliche
Kondensatoren und Filter einzusetzen.<ref name="ElSpec"/>

== Probleme==
MIDI wurde ursprünglich im Jahre 1982 von der Firma Roland eingeführt und ist aus heutiger Sicht veraltet. Das damals definierte Protokoll wurde für Einzelstimmengeräte erdacht und gestattet lediglich 7-Bit-Controllerwerte, wodurch Lautstärke und Stimmformung nur sehr grob eingestellt- und nicht ohne hörbare Stufen verändert ("gefaded") werden können.

Um dem abzuhelfen, wurden inzwischen für die meisten Controller Erweiterungen auf 14 Bits
eingeführt.<ref>[https://www.midi.org/specifications/item/table-3-control-change-messages-data-bytes-2 Control Change Messages]</ref><ref>[https://www.midi.org/downloads?task=callelement&format=raw&item_id=113&element=f85c494b-2b32-4109-b8c1-083cca2b7db6&method=download High Resolution Velocity Prefix] (PDF)</ref>

Was die Übertragungsgeschwindigkeit anbetrifft, sind die ca. 30 kHz der physikalischen Schnittstelle aber nach wie vor nicht geeignet, um viele Kanäle zu bedienen und mehrere gleichzeitige
Ereignisse, wie einen beidhändigen Akkordanschlag angemessen zu beschreiben:
Ein MIDI-Ergeinis benötigt mindestens 2 Bytes (bei kombinierten
Controllerwerten 6) wodurch 8 Finger auch ohne irgendwelche zusätzlichen
Controllerwerte bereits 16 MIDI Bytes erzeugen, was zu einer ungewollten Latenz
von 8ms für den letzen Wert gegenüber dem ersten führt. Durch die verschieden
langen Nachrichten kann es daher zu unmusikalischem,
unvorhersehbaren [[Jitter]] kommen. Komplexere Lautstärkemdulationen mit quasianalogen
MIDI-Gebern, wie bei der MIDI-Gitarre und MIDI-Flöte ("breath controller") sind
damit im Zusammenhang mit realer MIDI-Hardware nur sehr eingeschränkt verwendbar.

Auch das USB-Protokoll, welches immer häufiger zur Anwendung kommt, bietet zwar eine mehr als ausreichende Bandbreite, jedoch wird dies von nur wenigen Klangerzeugern unterstützt. Lediglich Softwaresampler und andere PC-basierte Systeme wie SW-Synthesizer sind damit zu steuern. Hierbei wirkt sich aber die PC-typische Latenz des Betriebssystems sehr negativ aus. Ein tatsächlicher Echtzeitbetrieb ist mit keinem derzeit auf dem Markt verfügbaren Gerät möglich.

== Erweiterungen ==
Statt des MIDI-Transports über die klassische serielle Verbindung, sind heute höhere Bandbreiten möglich, z.B. durch MIDI über USB oder Ethernet. Transportmethoden wie Parallelport (EPP) oder S/PDIF wurden ebenfalls realisiert, konnten sich aber aufgrund mangelnder Kompatibilität nicht durchsetzen bzw sind technisch überholt oder werden nur in Nischen oder Sonderanwendungen verwendet. Bei Geräten, die normalerweise nicht live eingesetzt werden, sondern an einen PC angeschlossen werden, hat sich MIDI über die USB-Schnittstelle durchgesetzt.

=== MIDI über USB ===
USB erlaubt höhere Bandbreiten, bei SuperSpeed bis zu 5 GBit/s. Die meisten derzeitigen MIDI-Geräte arbeiten aber noch mit Full Speed (12 MBit/s) oder High Speed (480 MBit/s). In der Praxis ist die Geschwindigkeit durch den Mikrocontroller und dessen Software im Endgerät sowie der PC-Infrastruktur begrenzt; üblich sind ca. 100 kBit/s.

Das USB-MIDI-Protokoll<ref>[http://www.usb.org/developers/docs/devclass_docs/midi10.pdf USB MIDI Devices 1.0] (PDF)</ref>
ist mit dem 'normalen' USB-Serial-Protokoll (CDC) nicht kompatibel; deshalb
ist es nicht möglich, USB-seriell-Konverter-Chips unverändert und ohne
zusätzliche Treiber für MIDI zu verwenden.

=== MIDI über FireWire ===
Von Yamaha und anderen Herstellern wurde 1999 das sogenannte Music-LAN definiert, welches auf FireWire basiert und vergleichsweise hohe Bandbreiten zugelassen hätte. Einige Teile des Protokolls wurden veröffenlicht und standardisiert<ref>[https://webstore.iec.ch/publication/6069 Consumer audio/video equipment - Digital interface - Part 6: Audio and music data transmission protocol]</ref>, vollständige Interoperabilität ist damit aber nicht möglich.

Da keine Möglichkeit zum Aushandeln einer höheren Geschwindigkeit definiert ist, ist die Bandbreite auf die normalen 3125 Bytes/s begrenzt<ref>[http://www.midi.org/techspecs/rp27v10spec(1394).pdf MIDI Media Adaptation Layer for IEEE-1394] (PDF)</ref>.

=== MIDI über Ethernet/WLAN: RTP-MIDI ===
Das Real-time Transport Protocol, das auf normalen UDP-Paketen basiert,
hat auch die Möglichkeit, MIDI zu übertragen<ref>[http://www.midi.org/aboutmidi/rtpmidi.php About RTP-MIDI]</ref><ref>[https://tools.ietf.org/html/rfc6295 RFC 6295: RTP Payload Format for MIDI]</ref>.

=== MIDI über Ethernet: AVB ===
IEEE-1722 (Audio/Video Bridging) definiert ein Protokoll zur Übertragung
von Multimedia-Information. Dabei ist es notwendig, dass alle beteiligten
Netzwerk-Karten und Switches/Router AVB in Hardware unterstützen.

AVB verwendet die gleichen Datenformate wie FireWire und hat die gleichen
Einschränkungen.

=== Serial wire MIDI ===
Mit Aufkommen der PCs gab es mehrere Versuche, die COM-Schnittstelle für schnellere MIDI-Kommunikation zu nutzen. Mitte der 90er waren PC-UARTs mit typisch 115k verfügbar. Diese wurden von Anwendern mittels proprietärer Software genutzt oder von Herstellern in einzelne Geräte integriert. Sehr bekannt sind die z.T. heute noch existierenden "TO HOST" Interfaces, die meist über MINI-DIN-Stecker erreichbar waren. Die Kommunikation erfolgte über einen eigenen Treiber.

=== Parallel-Port-MIDI ===
Ein Abkömmling des seriellen MIDIs sind Parallelportanwendungen, die aber nur bei einzelnen Geräten üblich waren. Oft wurden Mehrfach-MIDI-Controller mit einem Parallelport-Anschluss versehen, um die Datenrate für gleich mehrere MIDI-Geräte (in der Regel 8, seltener 16) bereitstellen zu können. Die ersten Geräte von M-Audio, MIDI-MAN und MOTU arbeiten auf diese Weise. Obwohl die Bandbreite praktisch verzehnfacht wurde, blieb es nur bei der Nutzung zwischen PCs und herstellerspezifischen Geräten. Die Protokolle sind meist nicht kompatibel.

=== MIDI over S/PDIF ===
Von unterschiedlichen Seiten wurde probiert, die limitierte Entfernung von MIDI-Verbindungen (meist 5m und weniger) durch Übersetzung auf alternative Protokolle zu vergrößern und die Verbindung auch störstabiler zu bekommen. Unter anderem wurde MIDI 2000 vorgeschlagen, welches das MIDI-Protokoll erweitert und in einen Stereo-[[S/PDIF]]-Datenstrom übersetzt und damit die Bandbreite praktisch um den Faktor 100 anhebt. Zum damaligen Zeitpunkt um die Jahrtausendwende waren bereits etliche Studiogeräte und Klangerzeuger mit S/PDIF ausgerüstet - auch Soundkarten mit S/PDIF-Ausgang waren verfügbar. Es blieb jedoch letztlich bei proprietären Applikationen, da sich von der PC-Seite her, [[USB]] 1.0 begann, durchzusetzen. Lediglich eine Firma weltweit bietet mit dem Gerät ES-4 einen S/PDIF-basierten MIDI-Übertragungsweg an.

=== MIDI over Audio ===
Um die limitierte Bandbreite bei MIDI zu überwinden, wurde schon in den 80ern vorgeschlagen, den MIDI-Datenstrom über Audiokanäle zu senden, um die dort vorhandene Infrastruktur für das Senden und Speichern zu nutzen. Da die MIDI-Bandbreite jedoch wegen der ca. 30kHz rund 100kHz beträgt, müssten 4 Audiokanäle belegt werden, was zum damaligen Zeitpunkt wegen der kaum verbreiteten 4-Kanal / bzw. Surround-Technik nicht für die Breite Masse der Nutzer einsetzbar war. Vereinzelt gelang es, ähnlich wie bei der Datasette im Computerbereich eine Speicherung vorzunehmen, indem eine erhöhte Bandbreite des Signals zusammen mit einer Kompression benutzt wurde. Später wurde Ähnliches mit den 48kHz-Digital-DAT-Recordern probiert, konnte sich aber nicht durchsetzen, weil die meisten Musiker noch analog aufzeichneten.

=== Sonstige ===
Für Sonderapplikationen gibt es eine Spezifikation für das Senden von MIDI über AES3 oder MADI.

=== MIDI HD ===
Seit 2005 berät sich das MIDI-Komitee über einen offiziellen Nachfolger der MIDI-Spezifikation<ref>[http://www.midi.org/aboutus/news/hd.php MIDI Manufacturers Investigate HD Protocol]</ref>.

== Siehe auch ==
=== Artikel auf Mikrocontroller ===
* [[Midi Rekorder mit MMC/SD-Karte]]

=== Beiträge auf Mikrocontroller ===
* [http://www.mikrocontroller.net/topic/48542 "Mr. MIDI" Player]
* [http://www.mikrocontroller.net/topic/102924 Schaltplan MIDI Controller]
* [http://www.mikrocontroller.net/topic/34376 Audio Projekt mit Spartan]
* [http://www.mikrocontroller.net/topic/223125 Midi Protokoll]
* [http://www.mikrocontroller.net/topic/240302 USB zu MIDI]
* [http://www.mikrocontroller.net/topic/191137 Effektgerät für Gitarre]
* [http://www.mikrocontroller.net/topic/140347 Midi mit Arduino]
* [http://www.mikrocontroller.net/topic/248226 DIY USB-MIDI interface]
* [http://www.mikrocontroller.net/topic/280923 ZEL MIDI Compiler]
* [http://www.mikrocontroller.net/topic/281154 Drum Computer]
* [http://www.mikrocontroller.net/topic/154781 USB MIDI IF]
* [http://www.mikrocontroller.net/topic/14798 MIDI mit AVR]
* [http://www.mikrocontroller.net/topic/326905 MIDI over WIFI]
* [http://www.mikrocontroller.net/topic/320743 MIDI Platinenselbstbau]
* [http://www.mikrocontroller.net/topic/295657 Eigenbau MIDI Controller]
* [http://www.mikrocontroller.net/topic/323354 MIDI mit BASCOM und AVR]
* [http://www.mikrocontroller.net/topic/330669 MIDI Orgel Schieberegister]
* [http://www.mikrocontroller.net/topic/320743 MIDI-Platine Eigenbau]

== externe Links ins Web ==
<references/>
* [http://de.wikipedia.org/wiki/Musical_Instrument_Digital_Interface MIDI in der Wikipedia]
* [http://www.midibox.org MIDI DIY Hardware mit Forum über MIDI mit vielen Projekten]
* [http://michd.me/blog/yearproject-fpga-midi-synth FPGA Midi Project Nexys]
* [http://papilio.gadgetfactory.net/index.php?n=Papilio.MIDIAudioWing steckbarer Midi und Audio Adapter]
* [http://synthesia.sourceforge.net/hardware.html Open Source Audio Hardware]
* [http://www.96khz.org/htm/midiviaspdif.htm 96kHz Audio DSP - high speed MIDI over S/PDIF]
* [http://www.edn.com/electronics-products/other/4312744/FPGA-evaluation-boards-come-with-design-software FPGa Evalboard mit Audio MIDI IO]
* [http://blog.makezine.com/2010/08/11/milkymist-interactive-vj-station/ Audio MIDI DSP Plattform]
* [http://www.indiamart.com/prayog-labs-limited/products.html Triple MIDI IF Adapter]
* [http://www.linux-community.de/Internal/Nachrichten/Video-Jockey-System-mit-offener-Hard-und-Software AV Controller System]
* [https://www.sparkfun.com/products/9595 MIDI shield Adapter]
* [http://www.ucapps.de/ uCApps.de - viele DIY MIDI Projekte]
* [http://truechiptilldeath.com/blog/2009/04/16/fpga-arcade-board/ FPGA Arcade Board]

[[Kategorie:Audio]]
[[Kategorie:Datenübertragung]]

S/PDIF

2016-12-07T21:07:04Z

87.178.118.118: /* Verwendung */

'''S/PDIF''' (Sony/Philips-Digital Interface Format) ist ein Protokoll zur Übertragung digitaler Audiodaten.
Gebräuchlich ist Stereo (2 Kanalton) bei Sampleraten von bis zu 192kHz und bis zu 24Bit.
Die Bits werden per biphase mark code [[BMC]] codiert.

S/PDIF ist in der IEC 60958 festgelegt.

== Beschreibung ==
Es handelt sich um eine serielle Verbindung über entweder optischen Lichtwellenleiter [[LWL]] oder elektrische abgeschirmte 2-Drahtverbindung [[COAX]].

Als Stecker und Buchsen wird der [[RCA]]-Standard ([[Cinch]]) mit 75Ω bei 0,5Vss bzw. das [[TOSLINK]]-System verwendet.

== Verwendung ==

S/PDIF wird benutzt, um HIFI-Elektronik auf digitalem Wege miteinander zu verbinden. Die Datenrichtung ist unidirektional.

Das Signal wird mit PLDs oder fertigen Chips codiert. Ein bekannter Hersteller für solche Chips ist Cirrus Logic. Die Anbindung erfolgt über eine synchrone, serielle Verbindung mit einem Worttakt. Bei [[I2S]] wird das erste Bit des neuen Wortes ein Takt nach dem Worttakt übermittelt. Weitere Formate beginnen oder enden genau mit dem Worttakt. Diese werden right-justified oder left-justified genannt.

== Aufbau ==
Die größte Einheit im S/PDIF Datenstrom ist der sogenannte Block. Er besteht aus 192 aufeinander folgenden Frames, die überwiegend alle gleich aufgebaut sind:
Jeder Frame besteht aus 2 (bei Stereo) Subframes. Es sind auch mehr als 2 Kanäle möglich.
Jeder Subframe besteht aus Preamble, 24-Bit Audio-Daten, Validity, Userdata, Channel-status und Parity Bits.

Alle Datenbits (also alles ausser der Preamble) sind BMC codiert. Damit ist die Polarität des S/PDIF / BMC Signals unwichtig.

Jedes Datenbit wird durch den BMC in zwei Leitungsbits übersetzt. Eine 0 enthält nur eine Flanke am Ende, eine 1 in der Mitte und am Ende eine Flanke:

<pre>
Daten | 0 | 0 | 1 | 1 | 0 | 1 |
BMC 1|0 0|1 1|0 1|0 1|0 0|1 0|1
</pre>

Diese Regel wird in der Präambel absichtlich verletzt. Während beim BMC keine längere Folge als 2 gleiche Bits hintereinander vorkommt, folgen in der Preamble 3 gleiche Bits hintereinander. Durch diese Besonderheit kann der Empfänger die Präambel also solche erkennen und sich synchronisieren. Es gibt 3 unterschiedliche Präambeln:Eine für den Blockstart, eine für den Framestart und eine für alle anderen Subframes. In Verbindung mit der Spiegelsymmetrie aufgrund der möglichen vertauschten Polarität ergeben sich 6 denkbare Präambeln:

* Preamble B (11101000 oder 00010111) steht am Blockanfang und enthält Daten von Kanal A, welches links bei Stereo ist.
* Preamble M (11100010 oder 00011101) steht am Anfang jedes Frames, welches nicht Blockanfang ist und enthält auch Daten von Kanal A.
* Preamble W (11100100 oder 00011011) steht am Anfang jedes Subframes, welches nicht Block- oder Frameanfang ist. Es enthält in Folge alle weiteren Kanäle ab B aufwärts. Bei Stereo nur B - also rechts.

Bei Stereo ergibt sich also folgendes Muster:
<pre>BWMWMWMWMWM.....WMWMWBWMWM...</pre>
Bei Vierkanalton
<pre>BWWWMWWWMWWW...</pre>

In jedem Subframe folgen der Preamble die Audiodaten. 24 Bit, LSB First. Bei 16 Bit Audio befinden sich in den ersten 8 Bits also nur Nullen. Damit ergibt sich praktisch die gleiche digitale Aussteuerung. Vereinzelt weichen jedoch manche Hersteller von dieser Festlegung ab.

Danach wird das Validity-Bit übertragen. Es sagt aus, ob das Sample gültig ist und wiedergegeben werden darf.

Darauf folgt das User-Bit. Hier kann der Sender Daten nach belieben absenden.

Dann folgt das Channel-Status Bit. Es ist bei allen Subframes eines Frames gleich. In einem Block sammeln sich so 192 Bits. Dies ist der sogenannte Subcode, in dem sich auch das Copy-Bit versteckt. Mehr dazu im nächsten Absatz.

Der Subframe wird vom Parity-Bit abgeschlossen. Die Parität ist immer gerade. Somit ist der Wert des Bits immer so, dass sich die Polarität der nächsten Preamble nicht ändert.

=== Channel-Status / Subcode ===
Die im Channel-Status übermittelten Bits starten mit dem Blockstart. Die in den W-Subframes übertragenen Bits haben den selben Wert, wie im vorangegangenen B- bzw. M-Subframe. Die 192 Bits haben folgende Bedeutung:

<pre>
Infos gültig, bei PRO-Bit = 0 - Also Consumer Mode

bit 0 1
------------- ------------------------- ------------------------------------------
0 PRO-Bit Consumer / S/PDIF (Professional / PRO / AES/EBU / 4-Channel)

1 Audio Kein Audio

2 C-Bit Kopierschutz aktiv Kopierschutz inaktiv
Bei einem Wechsel mit 4-10Hz und CatCode für CD darf nicht kopiert werden.

3 Keine Emphasis Emphasis 50/15us

4 Reserviert = 0
5 2 Kanal Audio 4 Kanal Audio
6-7 Mode (?) default = 00

8-14 catagory-code - siehe unten

15 L-Bit - siehe auch unten

16-19 Source 0-15, 0=Unspecified (16=LSB, 19=MSB)

20-23 Channel 0=Unspecified, 1=A (left), 2=B (right), ... 14=N, 15=O (20=LSB, 23=MSB)

24-27 Fs 0000 = 44.1kHz, 0100 = 48kHz, 1100 = 32kHz oder SRC (gibt es weitere für 88.2, 96, 176.4, 192kHz?)

28-29 Taktabweichung
lt. Analog Devices AN22: lt. Philips Service Manual f. DCC:
00 = Level II +/- 1000ppm (default) 00 = Level II +/- 50ppm
01 = Level III variable 01 = Level III +/- 1000ppm
10 = Level I +/- 50ppm 10 = Level I variable

Bits 30-191 sind ungenutzt / reserviert
</pre>

=== C Bit, L Bit und Category Code ===

In Abhängigkeit des Category Codes und des L-Bits, werden bei einer Kopie L und C Bit verändert.
Der Category Code ändert sich dabei in Abhängigkeit vom Gerät. Das Verfahren ist eine Wissenschaft für sich.

Abhängig vom Category Code kann die Veränderung des C und L Bits nämlich unterschiedlich ablaufen.
So ist z.B. die Aufnahme aus einem Musikinstrument mit gesetztem C und L Bit endlos kopierbar, wohingegen eine Aufnahme aus einem Gerät mit General Code (0000000) ebenfalls mit gesetztem C und L Bits nur zwei Generationen übersteht.

Zur Vereinfachung habe ich die Category Codes in 3 Gruppen eingeteilt:

Gruppe 1:
* 0000000 General
* 01100xx ADC ohne SCMS

Gruppe 2:
* 100xxxx Laser Optical (CD)
* 001xxxx Broadcast
* 0111xxx Broadcast

Gruppe 3:
* 0000001 Experimental
* 0001xxx Solid state Memory
* 010xxxx Digital/Digital converters
* 01101xx ADC mit SCMS
* 101xxxx Musikinstrumente
* 110xxxx Magnetical Tape or Disk

Zu Gruppe 1 lässt sich sagen, dass hier maximal 2 Generationen von einer Quelle mit C und L = 1, möglich sind.
Wiedergabe der ersten Generation gibt C=0 und L=1 und der zweiten Generation C=0 und L=0 aus.

Gruppe 2 und 3 verhalten sich gleich, solange C=1 ist. Beliebig viele Kopien sind möglich, C bleibt immer 1.

Bei Gruppe 3 nimmt bei C=0 und L=0 gar nicht auf, mit L=1 ist eine Generation möglich.

Gruppe 2 lässt mit C=0 und L=0 ein mal kopieren. Die Bits verändern sich nicht, aber der Category Code.

== Datenrate ==
=== Bandbreite ===
Da 64 Bit je Datenwort mit je 2 Takten übertragen werden müssen, beträgt der Datentakt ca 25 MHz. Das erfordliche Kabel muss also Bandbreiten bis etwa 100 MHz übertragen können.

=== Maximum ===
Praktisch werden mit COAX Übertragungsraten bis zu 384 kHz und 24 Bit pro Kanal erreicht, was aber besondere Übertrager benötigt. Üblich sind über die elektrische Verbindung nur 96kHz Stereo. Die normgemässen 192kHz sind meistens nur optisch möglich.

== Probleme ==
=== Jitter ===
Da kein Takt ausdrücklich übertragen wird, muss der Empfänger diesen rekonstruieren, was aufgrund des nicht 100%ig gleichstromfreien Codes und äusseren Einflüssen wie EMV nicht vollständig gelingen kann. S/PDIF-Datenströme addieren damit immer ein zusätzliches Phasenrauschen, das Jitter genannt wird und im Empfänger behandelt werden muss.

=== Datenformate ===
Vereinzelt wird berichtet, daß manche Hersteller eine nicht normgemäße Methode verwenden, um die Lautstärke der Endgeräte zu steuern, indem sie z.B. bei 16-Bit-Daten das Raster versetzen, da es so theoretisch möglich ist, die Auflösung an 24-Bit-taugliche Geräte weiterzugeben. Allerdings wird dies von den jeweiligen Endgeräten nicht immer richtig interpretiert und es kommt zu Auflösungsverlusten.

== Links ==
* [https://www.mikrocontroller.net/topic/397982 S/PDIF Daten interpretieren]
* [https://www.mikrocontroller.net/topic/402351 S/PDIF Buchsen]
* [https://www.mikrocontroller.net/topic/322113 Fragen zum S/PDIF Protokoll]
* [https://www.mikrocontroller.net/topic/39813 S/PDIF-Interface als HDL]
* [https://www.mikrocontroller.net/topic/381665 S/PDIF Impulsübertrager, Terminierung]
* [https://www.mikrocontroller.net/topic/83479 S/PDIF Transceiver auf FPGA]
* [https://www.mikrocontroller.net/topic/374766 Toslink / spdif AC-3]
* [https://www.mikrocontroller.net/topic/394195 S/PDIF Converter 2 Fragen]
* [https://www.mikrocontroller.net/topic/386405 S/P-DIF Mixer - lohnt sich selbst bauen]
* [https://www.mikrocontroller.net/topic/331467 digitaler Audioausgang für Raspberry Pi]

[[Kategorie:Audio]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Grundlagen]]
[[Kategorie:Multimedia]]