Forum: Mikrocontroller und Digitale Elektronik Fragen zum S/PDIF Protokoll


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Paul B. (Gast)


Lesenswert?

Nach dem Studium diverser Webseiten bin ich mir immer noch nicht 100% im 
Klaren, was ich damit wie übertragen kann.

Laut Wiki werden je Sample jeweils 2 Subframes a 32 bits übertragen und 
diese in 192er Blocks.

Wenn ich die resultierenden 64 Bits (bei Stereo logisch) den üblichen 
Takten zuordne, erhalte ich die auf enorama angegebenen Datenraten:

32000 Hz -> 2048000 bps
44100 Hz -> 2822400 bps
48000 Hz -> 3072000 bps

Siehe: http://www.epanorama.net/documents/audio/spdif.html



Nun habe ich 2 Probleme:

1) Wie übertrage ich 96kHz?
Sind das dann 96000, 6144000 bps? Das ist nirgends erwähnt.

2) Woher stammt die Sollfrequenz für S/PDIF auf Hamsterworks von 
5644800?
Ist das falsch, oder was Besonderes?
http://hamsterworks.co.nz/mediawiki/index.php/SPDIF_out

Habe ich noch Statusinfos innerhalb oder ausserhalb der 192er-Blocks 
übersehen?

von Mr. Claudius (Gast)


Lesenswert?

Frank P. schrieb:
> Nun habe ich 2 Probleme:
>
> 1) Wie übertrage ich 96kHz?
> Sind das dann 96000, 6144000 bps? Das ist nirgends erwähnt.

Ja. Bei 192kHz entsprechend 12,288Mbps.

>
> 2) Woher stammt die Sollfrequenz für S/PDIF auf Hamsterworks von
> 5644800?
> Ist das falsch, oder was Besonderes?
> http://hamsterworks.co.nz/mediawiki/index.php/SPDIF_out

Das liegt an der Manchestercodierung, bei einer '1' findet ein 
Pegelwechsel statt, eine '0' wird durch einen gleichbleibenden Pegel 
codiert, zwischen 2 Bits findet immer ein Pegelwechsel statt (ausser bei 
den Preambles). Der minimale Abstand zwischen 2 Signalflanken beträgt 
die halbe Bitlänge, daher wohl der um den Faktor 2 höhere Wert der 
Sollfrequenz.

von Paul B. (Gast)


Lesenswert?

Stimmt, die auf H.W. gefundene Frequenz ist exaktmdas Doppelte von den 
2822400 (44,1kHz). Tomaten auf den Augen gehabt.
Ich nehme an, wegen des tooglens der Freuqnz am Ausgang mit 50:50 wird 
das benötigt.

Für die 96kHz und 192kHz brauche ich also entsprechen mehr Frequenz. 
Fragt sich, wie man die krummen Werte exakt hinbekommt, ohne 
Spezialquarz.

von Sascha (Gast)


Lesenswert?

Stichwort PLL und VCO.

von Falk B. (falk)


Lesenswert?

@ Frank P. (frankyp)

>Für die 96kHz und 192kHz brauche ich also entsprechen mehr Frequenz.
>Fragt sich, wie man die krummen Werte exakt hinbekommt, ohne
>Spezialquarz.

Wieso krumm und spezial? 12,288 bzw. das Doppelte 24,576MHz sind 
Standardquarze im Audiobereich. Gibt es überall.

von Georg A. (georga)


Lesenswert?

...und selbst die 22.5792 bekommt man inzwischen deutlich besser als vor 
20 Jahren, wo ich mein erstes SPDIF-Interface für den Atari Falcon 
gebaut habe (mit CS8402 und CS8412). Da musste ich aber auch gleich eine 
ganze Tüte abnehmen. Liegt immer noch eine ganze Menge rum ;)

von Paul B. (Gast)


Lesenswert?

Ihr habt schon recht mit den Quarzen, aber ich will nicht noch mehr 
EIngänge und PLLs, sondern möglichst einen Takt für das Subsystem. Der 
Rest vom FPGA will ja auch noch arbeiten und braucht PLLs und Takte.

von Georg A. (georga)


Lesenswert?

Läuft halt nicht alles so wie du willst ;) 192/96/48 gehen schon mit nur 
einem Mastertakt für die 192, das lässt sich ja bequem in der 
Statemachine durch 2/4 teilen. Aber die 44.1 (die Vielfachen davon sind 
IMO recht unüblich) braucht einen Extraquarz oder mindestens eine 
rekonfigurierbare PLL.

Aus Qualitätsgründen sind zwei externe Quarze für 44.1/48 aber 
vermutlich am Besten. Ungünstig konfigurierte oder gestörte PLLs können 
das Audio-SNR durch Jitter deutlich reduzieren.

von Paul B. (Gast)


Lesenswert?

ok, ich sehe das Problem, wobei ich nur jeweils eine S/PDIF Frequenz für 
z.B. 96kHz bzw alternativ eine andere, aber nicht gleichzeitig brauche. 
Die Anforderungen sind hier aber nicht so hoch, dass man nicht etwas 
ungenau sein und etwas Jitter hinnehmen könnte. Ich möchte halt um 
zusätzliche Taktdomänen herum kommen und möglichst eine interne PLL 
nutzen. Wie genau muss denn S/PDIF sein?

von Ulrich P. (uprinz)


Lesenswert?

Also wenn Du das kommerziell machst, dann solltest Du Dir beim IEC die 
IEC60958-1 für das physische Interface und die IEC60958-3 für die 
Kommunikation auf Bitebene kaufen. Alternativ die IEC60958-4 für die 
commercial/professional audio Übertragungsverfahren.

Wenn das eine private Spielerei ist, dann google mal nach den obigen 
Normen und Du findest z.B. in der IEC60958-1
"7.1.3.2.5 Intrinsic jitter"
The peak intrinsic output jitter measured at all the data transition 
zero crossings shall be less
than 0,05 UI when measured with the intrinsic jitter measurement filter.

Da steht also bezüglich Signalformen und Abweichungen alles drin, was Du 
suchst, genauso steht in der -3 drin, welche Bits gesetzt sein müssen, 
damit die Gegenseite auch 192kHz oder andere Samplerates akzeptiert.

Gruß
Ulrich

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

Also ich hatte irgendwas mit 20ns in Errinnerung, was den Jitter angeht. 
Das dürfte sich aber auf die 48kHz beziehen. Ich bin aber nicht sicher! 
Das sollte aber mit einem modernen Baustein eh kein Thema sein.

Solange der Takt digital verarbeitet wird und nicht als Zeitbasis z.B. 
für einen Wandler dient, ist der Jitter ach unkritisch, solange er 
innerhalb gewisser Grenzenn bleibt. Ansonsten gilt, was Georg sagt, dass 
der Jitter die Signalqualitität reduziert, wobei es nicht eigentlich SNR 
ist, sondern eher THDN.

Du musst auch erstmal klären, ob Du den Takt vorgeben darfst oder Dich 
nicht auf einen anderen Takt synchen musst. Wenn Du selber am Dücker 
bist, kannst die klassischen S/PDIF Frequenzen, bzw. Vielfache davon mit 
einer 25MHz-PLL erzeugen: 25 MHz x 29 / 59 = 12.881 MHz mit Fehler im 
Bereich des Quarz / Jitters.

Wenn Du auf einen Fremdtakt synchen musst oder es genau brauchst, nimmst 
du einen externen Quarz, synchst Deinen internen Audiogenerator auf den 
eingehenden S/PDIF Takt, lässt ihn mit irgendeiner PLL-Konfiguration 
etwas schneller (also asynchron) laufen und benutzt ein ASYNCH FiFo am 
Ausgang, das mit dem Fremdtakt (oder eben dem OSC) geleert wird. Das ist 
signaltechnisch das Beste, weil die PLLs im FPGA so grandios grossartig 
stabil nicht sind.

von Paul B. (Gast)


Lesenswert?

Mr. Claudius schrieb:
> Ja. Bei 192kHz entsprechend 12,288Mbps.

ok, also falls es noch jemanden interessiert: Es gehen physisch sogar 
12.5 MHz, wenn man nicht unbedingt die SPEC einhalten will. Die externen 
Geräte machen da mit, zumindestens einige :-)

Danke nochmals an all für Ihre Erklärungen.

von J. S. (engineer) Benutzerseite


Lesenswert?

Frank Petelka schrieb:
> Die externen
> Geräte machen da mit, zumindestens einige :-)

Ich hatte damals Probleme, S/PDIF ans Laufen zu bekommen. Mit 12,5 MHz 
(wäre ja auch zu schön) ging es bei meinem Equipment nicht. Daher habe 
ich mir das krumme Übersetzungsverhältnis für die PLL oben einfallen 
lassen. Mein erster Synthie lief so. Passt dann auch genau zu den 256 
Stimmen (48kHz).

von Rolf S. (audiorolf)


Lesenswert?

Frank P. schrieb:
> ok, also falls es noch jemanden interessiert: Es gehen physisch sogar
> 12.5 MHz, wenn man nicht unbedingt die SPEC einhalten will.
Da würde mich aber doch nochmal interessieren, wie das funktioniert 
haben will? Wenn die Frequenz nicht passt, stimmen die ganzen 
Sampleraten nicht miteinander überein und damit auch nicht etwa die 
Zeiten oder Frequenzen.
Wenn einer damit Audio abspielt, wird alles ein "bizli" daneben sein.
Für den Ungeübten mag es angehen, aber Musiker werden da rebellieren, 
oder?

von J. S. (engineer) Benutzerseite


Lesenswert?

Wenn es sich um Material dreht, das ursprünglich mit korrekten 
Frequenten aufgenommen wurde und nun stur abgespielt wird, dann ja, dann 
ist das ein Problem. Anders ist es, wenn es darum geht, neues 
Audiomaterial zu generieren: Die zu erzeugenden Frequenzen können auf 
die Samplefreuenz umgerechnet werden und damit auf jede beliebige 
Abtastfrequenz angepasst werden.

von Denker und Hörer (Gast)


Lesenswert?

Rolf S. schrieb:
> Wenn die Frequenz nicht passt, stimmen die ganzen
> Sampleraten nicht miteinander überein und damit auch nicht etwa die
> Zeiten oder Frequenzen.
> Wenn einer damit Audio abspielt, wird alles ein "bizli" daneben sein.
> Für den Ungeübten mag es angehen, aber Musiker werden da rebellieren,
> oder?

Ich glaube ehrlich gesagt nicht, dass man DEN geringen Unterschied hören 
kann. Das sind nicht einmal 2% und es gab Cassetten und Tonbänder, die 
größere Gleichlaufschwankungen haben und die hat auch keiner gehört.

von Soul E. (Gast)


Lesenswert?

Denker und Hörer schrieb:

> Ich glaube ehrlich gesagt nicht, dass man DEN geringen Unterschied hören
> kann. Das sind nicht einmal 2% und es gab Cassetten und Tonbänder, die
> größere Gleichlaufschwankungen haben und die hat auch keiner gehört.

6% sind eine Note. Musiker rechnen in cent, das sind 0,6 Promille.

von J. S. (engineer) Benutzerseite


Lesenswert?

soul e. schrieb:
> 6% sind eine Note. Musiker rechnen in cent, das sind 0,6 Promille.

So ist es und man kann im AB-Vergleich schon 10% erkennen und die höhere 
von zwei Tonspuren festlegen.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Habt ihr mal gesehen, wie alt der Tread ist?

von J. S. (engineer) Benutzerseite


Lesenswert?

Knut B. schrieb:
> Habt ihr mal gesehen, wie alt der Tread ist?
Ein Zehntel so alt, wie das immer noch aktuelle S/PDIF Protokoll. :-)

Und mit Bezug zur Thematik noch dies:

Man kann sogar den oben angesprochenen Jitter im S/PDIF Signal hören. 
Nicht als Frequenzhub, sondern als Unsauberkeit in den Klängen - 
teilweise als verwaschenes Stereobild, besonders, wenn der hochfrequente 
primäre Jitter im Signal durch Glättungsmaßnahmen der PLL in untere 
Bänder geschoben werden.

Beitrag "Kriterien zur Charakterisierung der Klangqualität eines Audiosignalverarbeitenden Systems"

: Bearbeitet durch User
von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Unbestritten.

von Audiomann (Gast)


Lesenswert?

soul e. schrieb:
> 6% sind eine Note.
Eine HALBE Note. :-)

Jürgen S. schrieb:
> Man kann sogar den oben angesprochenen Jitter im S/PDIF Signal hören.
... und den Sauerstoff in den Kabeln können auch einige hören, hinzu 
kommt der Grad der Verdrillung, die Länge des Kabel sowie die Haarfarbe 
der chinesischen Arbeiterin, die das Kabel gebaut hat. Manche Audioleute 
hören viel, wenn der Tag lang ist.

Mal eine kleine Frage zum Thema:

Jürgen S. schrieb:
> Die zu erzeugenden Frequenzen können auf
> die Samplefreuenz umgerechnet werden und damit auf jede beliebige
> Abtastfrequenz angepasst werden.
Das würde ich gerne mal wissen, wie das gehen soll, wenn doch die 
Tonhöhe festliegt und nicht variiert werden kann, bzw kleine Änderungen 
nicht akzeptabel sind, wegen dem Raushören. Damit liegt doch die 
Frequenz des Tons ebenfalls fest. Wie und wo soll es da einen 
Freiheitsgrad geben, um sich auf die Abtastfrequenz anzupassen?

von Entwickler de Luxe (Gast)


Lesenswert?

Jürgen S. schrieb:
> Das ist signaltechnisch das Beste, weil die PLLs im FPGA so grandios
Für einen solchen Fall würde auch keineswegs eine FPGA-PLL empfehlen.

von Tom W. (Gast)


Lesenswert?

Was mich interessieren würde: Wie prozessiert man das im FPGA so, dass 
es mit der richtigen Taktfrequenz funktioniert? Es muss ja irgendeine 
Art von Taktrekonstruktion her. Können das die PLLs in FPGAs?

von Jobst M. (jobstens-de)


Lesenswert?

Audiomann schrieb:
> Das würde ich gerne mal wissen, wie das gehen soll

Schau mal nach Samplerate-Converter.


Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Thomas W. schrieb:
> Was mich interessieren würde: Wie prozessiert man das im FPGA so, dass
> es mit der richtigen Taktfrequenz funktioniert? Es muss ja irgendeine
> Art von Taktrekonstruktion her. Können das die PLLs in FPGAs?
Wenn die Daten nur verarbeitet werden sollen, reicht eine asynchrone 
Interpretation der Daten. Dann kann man eine Ratenkonversion einsetzen 
und mit jedem beliebigen Takt arbeiten. Besser und sinnvoller ist aber, 
sich an den Takt der Quelle drankzuhängen und sich drauf zu synchen. Das 
geht in FPGAs erfordert aber etwas Trickserei. Man muss den taktgebenden 
Oszillator ziehen und eine digitale PLL aufziehen. Die verfügbaren 
Audio-Chips machen das aber direkt mit. Vorzugsweise sollte man die 
verwenden und sich über z.B. über I2S an den Sampletakt dranhängen.

: Bearbeitet durch User
von Tom W. (Gast)


Lesenswert?

ok, danke!

von Rolf S. (audiorolf)


Lesenswert?

Denker und Hörer schrieb:
> Rolf S. schrieb:
> Ich glaube ehrlich gesagt nicht, dass man DEN geringen Unterschied hören
> kann. Das sind nicht einmal 2% und es gab Cassetten und Tonbänder, die
> größere Gleichlaufschwankungen haben und die hat auch keiner gehört.

Das haben schon manche gedacht und mussten sich überzeugen lassen. 
Gleichlaufschwankungen sind auch nicht so, daß die Tonhöhe so stark 
wechselt. Ein guter Recorder liegt unter 1%.

von Jobst M. (jobstens-de)


Lesenswert?

Mein Akai GX-95 soll 0,04% haben.

Gruß

Jobst

von A. F. (chefdesigner)


Lesenswert?

soul e. schrieb:
> 6% sind eine Note. Musiker rechnen in cent, das sind 0,6 Promille.

Kaum zu fassen! Bei ernst zu nehmender Musik kommt es auf höchste 
Präzision an. Wie sollen denn Geigen zusammen klingen, wenn sie nicht im 
Spektrum aufeinander abgestimmt sind? Da sind wenige Promille Abweichung 
schon entscheidend für Schwebungen und den Akkordklang.

Gleichlaufschwankungen oder digitaler Jitter sind da sehr störend. Wenn, 
müssten alle Kanäle gleich angehoben werden, bzw übertragen werden.

Jobst M. schrieb:
> Mein Akai GX-95 soll 0,04% haben.
Bei einem Japaner tut man sich schwer, an Qualität zu denken, aber die 
Marke war eine Gute, das kann ich bestätigen. Wie man hört und liest, 
produzieren die aber jetzt auch in Singapur und konzentrieren sich aufs 
Digitale.

von Jobst M. (jobstens-de)


Lesenswert?

Andreas F. schrieb:
> Bei einem Japaner tut man sich schwer, an Qualität zu denken,

Naja, Ende der 80er fand man im Hifi-Bereich ganz oben nur die Japaner.
(Nakamichi, Akai, Aiwa, Pioneer, Sony, Teac, Technics, Yamaha, Denon 
...)
Ein Spitzengerät von Telefunken, Grundig oder Philips war da auf jeden 
Fall nicht dabei. Aus Europa allerhöchstens Revox oder B&O.

Ende der 80er waren die Japaner qualitativ echt gut.
Im Automobilbereich sogar so gut, das VW Angst bekam und externe 
Mitarbeiter und Firmen mit japanischem Wagen nicht auf das Gelände 
gelassen hat.

Mittlerweile bekommt man ja kaum noch japanische Qualität, weil die 
Japaner, wie alle Anderen auch, in China produzieren lassen.



Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Als Massstab für gute Bandqualität und Gleichlauf würde ich aber nicht 
unbedingt "HiFi" hernehmen, sondern vielleicht an Firmen wie Studer 
denken.

von Tom W. (Gast)


Lesenswert?

Ich hätte eine Frage zum Thema, die auch hier reinspielt:
Beitrag "S/PDIF Daten interpretieren"

Es werden im Netz zahlreiche Jitterverbesserer angeboten. Hat jemand 
eine Vorstellung, was da geht und wie die arbeiten?

Ich meine, außer einem langen FIFO und einer guten PLL, die es hinten 
ausliest, kann man wohl kaum was tun, oder?

Kennt jemand wissenschaftliche Untersuchungen dazu, ab wann sich Jitte 
auswirkt?

von Jobst M. (jobstens-de)


Lesenswert?

Thomas W. schrieb:
> Es werden im Netz zahlreiche Jitterverbesserer angeboten. Hat jemand
> eine Vorstellung, was da geht und wie die arbeiten?
>
> Ich meine, außer einem langen FIFO und einer guten PLL, die es hinten
> ausliest, kann man wohl kaum was tun, oder?

Also das Teil von elektor hatte ein FlipFlop und zwei ziehbare Quarze.
Das empfangene Halb-Bit wurde zwischengespeichert und dann mit Quarztakt 
wieder rausgetaktet. So groß wie ein Bit wird der Jitter nicht. Wenn 
doch, ist was grob faul.

> Kennt jemand wissenschaftliche Untersuchungen dazu, ab wann sich Jitte
> auswirkt?

Ich denke, das ist von Person zu Person und von Musikmaterial zu 
Musikmaterial unterschiedlich. Wissenschaftliche Untersuchungen sind mir 
nicht bekannt, mag es aber sicher geben. Evtl. mal selber einen Versuch 
starten?

Bisher hatte ich mit Jitter allerdings nie wirkliche Probleme.


Machst Du an Deinem PLD-Projekt weiter?
Benutze eine externe PLL! :-)


Gruß

Jobst

von Tom W. (Gast)


Lesenswert?

Wie funktioniert das mit den ziehbaren Quarzen?

Ja, ich mache gfs weiter.

von Jobst M. (jobstens-de)


Angehängte Dateien:

Lesenswert?

Varicap parallel zum Quarz. Evtl. entfallen dadurch die normalen 
Lastkondensatoren.

Gruß

Jobst

von Andi B. (andi_b2)


Lesenswert?

Thomas W. schrieb:
> Es werden im Netz zahlreiche Jitterverbesserer angeboten.

Da würde sich mir zuallererst die Frage stellen wozu? Abgesehen davon, 
dass meine Quellen sicher nur sehr wenig jittern, mein einziges Ziel für 
S/PDIF ist für mich mein Surround Verstärker. Und der macht das intern 
sicher 100x besser als irgendeine externe Bastelschaltung.

> Kennt jemand wissenschaftliche Untersuchungen dazu, ...

Zu was? So auf die Art der Denon verträgt soviel % Jitter bevor er 
aussteigt und der Yamaha soviel? Oder willst du ver-jittertes ( :-( ) 
Signal direkt auf deinen selbstgebastelten DAC und AMP legen? Dann 
stellt sich die Frage, wie produzierst du eigentlich den vielen Jitter 
der dir Sorgen macht und sollte man da dann nicht eher an der Quelle 
ansetzen?

von Sascha W. (sascha-w)


Lesenswert?

Andi B. schrieb:
> Thomas W. schrieb:
>> Es werden im Netz zahlreiche Jitterverbesserer angeboten.
>
> Da würde sich mir zuallererst die Frage stellen wozu? Abgesehen davon,
> dass meine Quellen sicher nur sehr wenig jittern, mein einziges Ziel für
> S/PDIF ist für mich mein Surround Verstärker. Und der macht das intern
> sicher 100x besser als irgendeine externe Bastelschaltung.
>
>> Kennt jemand wissenschaftliche Untersuchungen dazu, ...
>
> Zu was? So auf die Art der Denon verträgt soviel % Jitter bevor er
> aussteigt und der Yamaha soviel? Oder willst du ver-jittertes ( :-( )
> Signal direkt auf deinen selbstgebastelten DAC und AMP legen? Dann
> stellt sich die Frage, wie produzierst du eigentlich den vielen Jitter
> der dir Sorgen macht und sollte man da dann nicht eher an der Quelle
> ansetzen?

Wahrscheinlich sollte man auf jeden Fall optische S/PDIF-Kabel mit 
vergoldeten Steckern verwenden.

Sascha

von Jobst M. (jobstens-de)


Lesenswert?

Andi B. schrieb:
> Abgesehen davon, dass meine Quellen sicher nur sehr wenig jittern,

Du hast das Problem offensichtlich nicht verstanden. Die Quellen sind es 
nicht.


> mein einziges Ziel für S/PDIF ist für mich mein Surround Verstärker.
> Und der macht das intern sicher 100x besser als irgendeine externe
> Bastelschaltung.

Ich fürchte, dass ich Dich entäuschen muss. Der wird in dieser Richtung 
sicherlich gar nichts machen.


Andi B. schrieb:
>> Kennt jemand wissenschaftliche Untersuchungen dazu, ...
>
> Zu was? So auf die Art der Denon verträgt soviel % Jitter bevor er
> aussteigt und der Yamaha soviel?

Nein, die Hardware steigt nicht aus. Es klingt nur doof.

> stellt sich die Frage, wie produzierst du eigentlich den vielen Jitter
> der dir Sorgen macht und sollte man da dann nicht eher an der Quelle
> ansetzen?

Für jemanden, der überhaupt keine Ahnung hat, hast Du eine verdammt 
große Klappe. Der Jitter entsteht vor allem in den Leitungen. Vor allem 
optisch.
Es ist mess- und hörbar. Auch ohne Hifi-Voodoo.


Gruß

Jobst

von Georg A. (georga)


Lesenswert?

> Es ist mess- und hörbar. Auch ohne Hifi-Voodoo.

Effektiv produziert der Jitter eine Frequenzmodulation des 
DA-gewandelten Signals. Gab dazu mal ein gutes Paper in einem 
Crystal/Cirrus-Datenbuch, in dem das genau besprochen wurde. War aber 
prä-PDF-Zeiten, im Web findet sich das zumindest nicht auf Anhieb.

Aus meinen SPDIF-Bastelzeiten so gegen '93 rum weiss ich jedenfalls 
noch, dass ein PLL-Jitter von ca. 0.5ns (der auf einem HM604 gerade so 
erkennbar war) bereits ein deutlich hörbares Zusatzrauschen (also sicher 
<-60dB) auf dem DAC-Ausgang produziert hat. Fand ich dann doch 
erstaunlich und hat mich genötigt, sich doch mal eingehender mit 
Schleifenfiltern zu beschäftigen ;)

von Clemens L. (c_l)


Lesenswert?

Georg A. schrieb:
> Effektiv produziert der Jitter eine Frequenzmodulation des
> DA-gewandelten Signals. Gab dazu mal ein gutes Paper in einem
> Crystal/Cirrus-Datenbuch, in dem das genau besprochen wurde. War aber
> prä-PDF-Zeiten, im Web findet sich das zumindest nicht auf Anhieb.

http://audioworkshop.org/downloads/AES_EBU_SPDIF_DIGITAL_INTERFACEaes93.pdf

von J. S. (engineer) Benutzerseite


Lesenswert?

Jobst hat schon recht: Durch den Jitter kann es sowohl zu analogen, als 
auch digitalen Problemen kommen. Die Geräte haben allesamt irgendeine 
Art von PLL, die den Takt glättet und damit externen Jitter reduziert 
und internen induziert. Das genau produziert die falschen 
Zeitinformationen, die sich dann auf den Wandler übertragen, der gar 
nichts anders tun kann, als falsch zu wandeln.

Je besser (= träger) die PLL ist, desto besser ist die externe 
Jitterunterdrückung, was sicher jedem einleuchtet. Dummerweise führt 
eine sehr träge PLL aber dann in der Tat zu einem so großen Offset 
zwischen dem Takt und dem zu sampelnden Signal, dass Lesefehler 
auftreten. Sehr ärgerlich ist es, dass auf diese Weise ausgerechnet 
hochwertiges Studioequipment gerne mal aussteigt, wenn es von 
Consumersignalen gefüttert wird, während der 99,- Euro Billigrecorder 
das miese Signal tolerant frisst. Den dreimal höheren Jitter hört der 
Nutzer nicht.

Ein FiFo ist, wie vermutet, dann in der Tat sehr hilfreich, aber nur, 
wenn er mit dem Eingangstakt gefahren wird, der ja unbekannt ist. Beim 
S/PDIF z.B. muss dieser Takt erst gebildet werden. Die saubere Lösung 
ist daher nach meiner Auffassung die, eine schnelle und wenig glättende 
PLL zu realisieren, die dem Takt gut folgt und die Datenbits sauber und 
hochtolerant interpretiert. Das kann mit entsprechender Logik und 
Überabtastung total asynchron erfolgen. In einem zweiten Schritt werden 
die Daten in das Fifo geschoben, das hinten von einem sehr trägen Takt 
ausgelesen wird. Über die Pointer im Fifo muss eine Regelung, die den 
Ausgangstakt ganz weich nachstellt.

Leider braucht es da FiFos von wenigstens mal 100ms und mehr, um die 
Regelung träge genug halten zu können, damit Tonhöhenänderungen im 
Bereich von wenigen Cent / Sekunden stattfinden und nicht etwa 
Klangveränderungen erzeugen. Leider sind / waren nicht alle 
Audiogerätehersteller, die ich so kenne(ngelernt habe) für diese 
Argumentation empfänglich und bauen mit kleinem Fifo, oder ohne und 
nehmen das als Takt, was der Dekoderchip als solchen ausgibt.

Und es gibt halt den Fall der Echtzeitanwendungen, wo man keine große 
Verzögerung haben will.

: Bearbeitet durch User
von Georg A. (georga)


Lesenswert?

Hm, wie kann bei einem gleichverteiltem Jitter im Bereich einiger ns 
eines ansonsten konstanten (Quarz)Takts auch eine langsame PLL 
langfristig soweit weg von der realen Samplerate sein, dass man zig ms 
an Buffer braucht?

Mag sein, dass das beim Einschwingen der PLL nötig wäre. Aber zum einen 
kann man den Sync-Zeitraum ignorieren, zum anderen könnte man den 
Schleifenfilter fast/slow umschalten (wie es diverse RF-Frontend-PLLs 
auch machen).

von Jobst M. (jobstens-de)


Lesenswert?

Georg A. schrieb:
> Hm, wie kann bei einem gleichverteiltem Jitter im Bereich einiger ns
> eines ansonsten konstanten (Quarz)Takts auch eine langsame PLL
> langfristig soweit weg von der realen Samplerate sein, dass man zig ms
> an Buffer braucht?

Braucht man auch nicht. Siehe oben die angehängte Schaltung. Man 
benötigt ein Bit / FlipFlop.

Dort macht man einfach:
1
     ___            ________       ___
2
___//   \\________//        \\___//
3
       ____           _________      ____
4
______|    |_________|         |____|


Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Damit detektierst Du aber nur die Flanken im Signal. Das reicht noch 
nicht so ganz für den Takt :-)

Zu der FiFo-Länge:

Es geht nicht nur um den digitalen Jitter auf Taktebene, sondern auch um 
den Gleichlauf. Wenn man einen Quarz einfach nur laufen lässt, dröhnt 
der mit SEINER Frequenz und die ist leicht daneben. Daher gibt es in 
hochwertigen Systemen eine Regelung, die den Takt hinzieht. Ich habe das 
z.B. für einen Sender realisiert, der sich auf die Atomuhr der PTB 
synchronisieren kann.

Das Signal wird dazu exakt vermessen und der Grundtakt des Quarzes 
bestimmt und durch Ziehen korrigiert. Alternativ kommt noch eine 
eventuelle zweite Information aus externen Geräten, die den Sender auf 
den Systemtakt einstellen wollen. Im Studio ist das der Work clock. Im 
beiden Fällen gibt es Störungen im Bereich hörbarer Frequenzen, mit 
denen der Takt driftet.

Wenn die PLL im Endgerät jetzt zu schnell folgt, und das tut sie in der 
Regel, übernimmt sie den Jitter. Also legt man die Grenzfrequenz der 
Regelung dort auf 5Hz und darunter, lässt die PLL entjittern, selber 
jittern und zieht sie im Mittel zurecht. Wenn dann das externe Signal 
ein wenig wegläuft, geht der Empfänger unhörbar mit.

"Ein wenig weglaufen" können hier ohne Weiteres 50 ppm Verstimmung und 
mehr sein, die es beim Audiostart aufzuholen gilt. Massgeblich ist der 
neue Takt nach z.B. Umschalten in broad cast Einrichtung oder bei 
digitalen Mikrofonen etc ... Das sind bei z.B. 192kHz S/PDIF >600 Takte 
in der Sekunde, die man weich nachziehen muss. Je nach Regelung 
entstehen dann dynamische Differenzen von einigen hundert Takten in 
beide Richtungen.  Das erfordert zunächst ein FIFO von "nur" rund 10 
Worten. Wenn aber wie im Fall des unsynchronisierten Betriebes der 
Jitter verschwinden- und der Datenstrom in die neue Domäne gerechnet 
werden soll, braucht man zusätzlich den Betrachtungszeitraum der 
Regelung also 200ms für 5Hz, um den Jitter rückzurechnen und zu 
interpolieren. Üblicherweise werden aber nur die üblichen 20ms 
spendiert, die zur Erfassung und Berechnung des Audiosignals an sich 
erforderlich sind.

Beim Radar macht es aber genau so und auch beim Ultraschall verfährt man 
so, wenn es um die Korrelation der gesendeten Welle und der empfangenen 
geht. Ist aber jetzt zu Speziell.

von Jobst M. (jobstens-de)


Lesenswert?

Jürgen, schau Dir bitte die Schaltung an. Die funktioniert. Mit einem 
Flip-Flop. Bau sie auf und wundere Dich.


Gruß

Jobst

von Andi B. (andi_b2)


Lesenswert?

Jobst M. schrieb:
>> mein einziges Ziel für S/PDIF ist für mich mein Surround Verstärker.
>> Und der macht das intern sicher 100x besser als irgendeine externe
>> Bastelschaltung.
>
> Ich fürchte, dass ich Dich entäuschen muss. Der wird in dieser Richtung
> sicherlich gar nichts machen.
> ....
> Für jemanden, der überhaupt keine Ahnung hat, hast Du eine verdammt
> große Klappe.

Und das alles weißt du weil du für die namhaften Hersteller die 
Eingangselektronik entwickelst und die DSPs programmierst? Respekt. Ich 
wusste gar nicht, dass die dafür den Flip-Flop Jobst brauchen damit er 
ihnen die Welt erklärt :-)

: Bearbeitet durch User
von Jobst M. (jobstens-de)


Lesenswert?

Andi B. schrieb:
> Und das alles weißt du weil du für die namhaften Hersteller die
> Eingangselektronik entwickelst und die DSPs programmierst? Respekt.

Ich verrate Dir jetzt mal einen Tipp, bevor Du weiter Deine Unwissenheit 
zur Schau stellst: Service Manuals. Da kann man reinschauen, wie der 
Hersteller das gelöst hat. Und der DSP wird meist mit dem fertig 
aufbereitetem Problem konfrontiert.


> Ich
> wusste gar nicht, dass die dafür den Flip-Flop Jobst brauchen damit er
> ihnen die Welt erklärt :-)

Nur kein Neid. Aber die brauchen den nicht. Denn Jitter ist gar nicht 
deren Problem. Deren Problem ist, wie verkauft man möglichst billigen 
Kram für viel Geld.
Aber kein Problem, dafür gibt es Leute, die fest daran glauben, dass der 
DSP Jitter beseitigt.


Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Jobst M. schrieb:
> schau Dir bitte die Schaltung an. Die funktioniert. Mit einem
> Flip-Flop. Bau sie auf und wundere Dich.
Worauf beziehst Du Dich hierbei? Auf die komplette oben gelinkte 
Entjitter-Schaltung aus dem Elektor oder nur auf das FlipFlop?

Was genau soll das leisten?

Ich hatte die Skizze so verstanden, daß der S/PDIF-Datenstrom mit dem 
Takt des Empfängers einsynchronisiert wird und damit eine typische 
Flankenerkennung realisiert wird. Wie sollte der Jitter beseitigen? Man 
erhält ein mit der halben Rate wechselndes FlipFlop, welches Jitter nur 
im Rahmen der Dauer der Flankenwechsel reduziert, weil es praktisch 
aufintegriert, das aber noch keinen 50:50 Takt liefert, mit dem man eine 
PLL sauber takten könnte.

Daran angeschlossen werden müsste eine digitale PLL, die die Bits 
sampeln kann und sie in ein FIFO schreibt. Das kann komplett aysnchron 
geschehen. Alternativ braucht es eine einigermassen tolerante PLL mit 
deren Takt man das bit mittig erwischt.

Mit der Bit-Schaltung oben kannst Du zunächst mal nur das bit selbst aus 
dem MBC extrahieren.

: Bearbeitet durch User
von Jobst M. (jobstens-de)


Lesenswert?

Jürgen S. schrieb:
> Worauf beziehst Du Dich hierbei? Auf die komplette oben gelinkte
> Entjitter-Schaltung aus dem Elektor oder nur auf das FlipFlop?

Auf die Schaltung von Elektor.

> Was genau soll das leisten?

Vom Eingangssignal wird in einer recht pfiffigen Schaltung der Takt 
zurück gewonnen. Dabei wird nur zu jedem 8. Takt auf die Flanke 
geschaut. Da muss immer eine sein!
Sollte die Flanke nicht ungefähr dort sitzen, wird der Quarz 
nachgeregelt oder im Extremfall auf einen anderen umgeschaltet.
Die Quarzfrequenz wird auf 128fs geteilt und zusammen mit den 
Eingangsdaten auf ein D-FF gegeben, aus welchem die sauberen Bits 
purzeln.
Die 128fs aus dem Quarz treffen mit steigender Flanke immer die Mitte 
der Bits.

Mit Bits meine ich immer die Kanalbits, nicht die Datenbits im 
Datenstrom.

Noch einmal ein Diagramm:
1
    ___         ___               _________         ___
2
(1)    \\\___///   \\\_________///         \\\___///   \\\_____
3
    _       _________________________________________       ___
4
(2)  |_____|                                         |_____|
5
    _     ___________________________________________     _____
6
(3)  |_///                                           |_///
7
         _______________________                         ______
8
(4) ____|                       |_______________________|
9
      __    __    __    __    __    __    __    __    __    __
10
(5) _|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__
11
    _______       _____             ___________       _____
12
(6)        |_____|     |___________|           |_____|     |_____


1. Eingangssignal (/// = Jitternde Flanken)

2. Fenster, in dem der Frequenzkomperator nach Flanken schaut (Low)

3. Rücksetzen des Frequenzkomperators durch Flankenwechsel im 
Eingangssignal.

4. Geteilte Quarzfrequenz (16fs) mit welcher (3) im 4046 verglichen 
wird. Die Regelung ist träge und sowieso nur mit wenig Wirkung, da ein 
Quarz gezogen wird.

5. 128fs aus dem Quarz an Clock vom D-FlipFlop (IC3b)

6. Eingangssignal nach FlipFlop um einen halben Takt verzögert. Die 
Daten werden bei positiver Flanke der 128fs übernommen.



Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Das dachte Ich mir :-)

Und das ist genau das, was ich angesprochen habe: Das Sampeln des 
S/PDIF-Daten-Bits, also das "richtig reinkriegen" ist nicht das Problem. 
De-Jittering braucht zwei Dinge: Toleranz gegen den ankommenden Jitter 
und die Fähigkeit, einen stabilen Takt auszugeben.

Mit nur einer Architektur, die taktmäßig zusammenhängt (und das tut die 
Elektorschaltung) bildet sich ein Kompromiss: Je träger die PLL, desto 
besser der Ausgang, aber desto weniger budget gegenüber dem Eingang. 
Daher sind PLLs oft auch einstellbar (inzwischen auch in FPGAs). Konkret 
liefert die Elektorschaltung wenn sie jedes 8 Bit aufnimmt, einen 
digitalen Impuls auf (die Steuerung der) PLL, die dann träge reagiert. 
Sie darf dabei maximal ein halbes Sample weglaufen, weil sonst ein 
Aussetzer droht. Konkret sind das z.B. 48kHz x 64 / 8 = 384kHz, die von 
der PLL tiefpassgefiltert werden. Die daraus resultierenden Frequenzen 
liegen voll im Audioband. Das ist der Standard, oft anzutreffen und in 
zahlreichen Geräten realisiert - durchaus auch intelligenter, als im 
Elektor :-)

Mein Vorschlag trennt aber die beide Aspekte, hält also die GF der 
Schaltung für den Eingang hoch und setzt sie gleichsam für den Ausgang 
hinab. Diese Konfiguration ist stabiler gegen analoge Schwankungen.

- Im Fall der Nutzung einer digitalen PLL am Eingang kann man zudem 
Aussetzer und sogar physikalische Fehler im Primärsignal überlesen. Dazu 
muss der Datenstrom entsprechend reinterpretiert werden. Was dann 
bereits einen längeren Fifo also die erwähnten "ca 10 Samples" (siehe 
mein Beitrag oben) erfordert.

- einen noch größeren FiFo braucht es, wenn man den im Primärsignal 
enthaltende Jitter beseitigen will, der durch die Aufnahme entstanden 
ist, der also durch den jitternden Wandler erzeugt wurden und nicht 
durch die Übertragung kommen. Das sind die erwähnten Anteile im unteren 
Band 5 Hz abwärts, wobei das natürlich eine Spezialanwendung ist.

von Rolf S. (audiorolf)


Lesenswert?

Jobst M. schrieb:
> Mein Akai GX-95 soll 0,04% haben.
> Jobst

Ok, dann verschärfe Ich meine Aussage dahingehend, dass die guten 
Rekorder unter 1Promille Gleichlauf haben. Ich glaube aber, dass bei den 
Angaben auch getrickst wird, weil der Bezugspunkt ja willkürlich ist. 
Man könnte die Abweichung ja auf einen größeren Zeitraum beziehen.

von Jobst M. (jobstens-de)


Lesenswert?

Die Angabe soll nach DIN sein.
Akai gibt außerdem noch 0,025% WRMS an.

Der Nakamichi Dragon hat 0,04% peak und 0,019% rms

Das Revox B 77 HS Spulentonbandgerät schafft gerade 0,05% nach DIN.
Akai Tonbandgeräte habe ich mit 0,07% nach DIN gefunden.



Gruß

Jobst

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

Jobst M. schrieb:
> Der Nakamichi Dragon hat 0,04% peak und 0,019% rms
> Das Revox B 77 HS Spulentonbandgerät schafft gerade 0,05% nach DIN.
> Akai Tonbandgeräte habe ich mit 0,07% nach DIN gefunden.

Ja, diese Geräte haben teilweise erstaunliche Qualitätswerte, die jene 
der einfachen Digitaltechnik bequem übertreffen. Vor allem wenn man sich 
den Jitter bei Soundkarten und AD-Wandlern in Billigdigitalrecordern 
ansieht. Es gibt heute noch Toningenieure, die mit analogen 
Bandmaschinen arbeiten.

von Rolf S. (audiorolf)


Lesenswert?

Eine Frage in die Runde zur Schaltungsphysik:

Wenn Ich die Tabelle des TE im Eingangsposting weiterzähle,

müssten die derzeit gültigen 192kHz, mit 12,288bps arbeiten.

Schon dafür bekommt man kaum einen Übertrager oder einen 
TOSLINK-Adapter.

Wie machen das die Leute, die mit 384kHz arbeiten? Geht symmetrisch über 
EBU mehr?

von Jobst M. (jobstens-de)


Lesenswert?

Rolf S. schrieb:
> müssten die derzeit gültigen 192kHz, mit 12,288bps arbeiten.
>
> Schon dafür bekommt man kaum einen Übertrager oder einen
> TOSLINK-Adapter.

?

12MHz sind für Übertrager lächerlich. Damit kann man bis in den GHz 
Bereich.
Übertrager für SPDIF wickelt man mit wenigen Windungen selbst.

Toslinks mit 15Mb/s findet man sowohl bei Sharp, als auch bei Toshiba 
problemlos. Da hast Du offenbar nicht gut genug gesucht.


> Wie machen das die Leute, die mit 384kHz arbeiten?

Kompression oder Mono-Mode. Oder welche hochqualitative (also 
unkomprimierte) 384kHz-Quelle soll das sein?

> Geht symmetrisch über EBU mehr?

Mit Koax kann man bei korrekter Auslegung und vernünftigem Kabel mit 
SPDIF genau so schnell wie symetrisch ('EBU').


Gruß
Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Für 384kHz wird es optisch aber schon ein bissl eng. Elektrisch geht das 
aber durchaus. Habe Ich schon gemacht. Geräte gibt es da allerdings 
keine soweit Ich weiß. Die werden nur zur Abtastung genutzt. Die neue 
RME macht das z.B. , übertragen aber über MADI.

Die Übertrager sind bei hohen Frequenzen erstaunlicherweise zunehmend 
weniger  das Problem, weil man die kapazitiv trimmen oder gleich so 
auslegen kann. Fertige Übertrager arbeiten auch oft schon mit ihren 
parasitären Kapazitäten. Das hatten wir heute schon mal irgendwo in 
einem anderen thread.

>Mit Koax kann man bei korrekter Auslegung und vernünftigem Kabel mit
>SPDIF genau so schnell wie symetrisch ('EBU').
Aber nicht so weit und nicht so störsicher. EBU ist RS422.

von J. S. (engineer) Benutzerseite


Lesenswert?

Zum Thema Resampeln:

Audiomann schrieb:
> Jürgen Schuhmacher schrieb:
>> Die zu erzeugenden Frequenzen können auf
>> die Samplefreuenz umgerechnet werden und damit auf jede beliebige
>> Abtastfrequenz angepasst werden.
> Das würde ich gerne mal wissen, wie das gehen soll, wenn doch die
> Tonhöhe festliegt und nicht variiert werden kann, bzw kleine Änderungen
> nicht akzeptabel sind, wegen dem Raushören. Damit liegt doch die
> Frequenz des Tons ebenfalls fest. Wie und wo soll es da einen
> Freiheitsgrad geben, um sich auf die Abtastfrequenz anzupassen?

Indem man die Klänge generisch erzeugt und sich auf die "falsche" 
Frequenz anpasst. Gibt eben dann bei der digitalen Aufnahme ein Problem, 
weil die Aufnahmehardware sich zwar drauf synched, später das Audio aber 
normal abspielt. In dem Fall wäre es besser, die Audiodaten ungeändert 
abzuspielen, um sie zwar zu schnell zu überspielen, aber dann richtig im 
Kasten zu haben.

Ich habe das schon so gemacht, 48kHz-Daten als 96kHz zu überspielen und 
zu bearbeiten. Klappt, wenn man die Zeitbasis der bearbeitenden 
Prozessoren auch entsprechend ändert, z.B. die Attack-Zeiten von 
Kompressoren und die Grenzfrequenzen der Equalizer. Hört sich dann real 
Mickey-Mouse-like an :-) später passt es.

Das geht mit jeder krummen Frequenz: Beim Access Virus z.B. gab es mal 
eine Diskussion zur Abtastrate der Wandler. Die hat keine 44,1 oder 48k, 
sondern 49kirgendwas. Das Problem war, daraus digitale Daten zu ziehen. 
Die musst man quasi resampeln. Um das zu umgehen, habe Ich die Daten als 
48k Daten reingenommen und unverändert gespeichert. Damit war das 
abgespielte Stück zu lang und tief. Um das zu kompensieren, dreht man 
beim Abspielen die Tonhöhe und den Speed etwas hoch.

von Jobst M. (jobstens-de)


Lesenswert?

Jürgen S. schrieb:
> Aber nicht so weit und nicht so störsicher. EBU ist RS422.

Wie weit möchtest Du?
Mit Antennenkabel für Radio- und TV-Installationen schafft man über 1km.
Was will man mehr?


Gruß
Jobst

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Jobst M. schrieb:
> 12MHz sind für Übertrager lächerlich. Damit kann man bis in den GHz
> Bereich.
> Übertrager für SPDIF wickelt man mit wenigen Windungen selbst.

Muss man nicht mal. Ich habe mit gutem Erfolg Ethernet Übertrager 
benutzt bei 48kHz Samplerate und der Pegel und die Flanken machten dabei 
nicht den Eindruck, als würden sie bei 96kHz einbrechen oder verrundet 
werden. Das ganze habe ich dann auf 10m Koaxkabel R/G-59U geschickt und 
mit der Terratec Phase 88 PCI empfangen. Null Probleme dabei.
Gebuffert wurde das 3,3V S/PDIF Signal aus dem DSP meines 
Bassverstärkers dabei von 5 parallel geschalteten Gattern des 74HC14 und 
dann auf den Übertrager geschickt.

: Bearbeitet durch User
von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Jürgen S. schrieb:
> Um das zu kompensieren, dreht man beim Abspielen die Tonhöhe und den
> Speed etwas hoch.

Was ist das anderes als Resampeln?

von Jobst M. (jobstens-de)


Lesenswert?

Matthias S. schrieb:
> Ethernet Übertrager

Stimmt, die habe ich zu diesem Zweck auch schon eingesetzt. Allerdings 
tatsächlich auch auf Ethernet-Leitungen. (Vorhandene Infrastruktur 
nutzen).

Kleiner Nachteil der Ethernet-Übertrager: Sie haben meist ein 
Windungsverhältnis von 1:1 oder 1:1,25 oder sowas.


Gruß
Jobst

von A. F. (chefdesigner)


Lesenswert?

Andi B. schrieb:
> So auf die Art der Denon verträgt soviel % Jitter bevor er
> aussteigt und der Yamaha soviel?

Es geht glaube Ich nicht, um das "Vertragen des Jitters" dass er 
aussteigt oder nicht, sondern daraum, wie er sich dazu verhält. Das 
Thema gibt es bekanntlich bei jeder digitalen Synchronisation. 
Langfristig muss sich die Senke auf die Quelle angleichen und dazu wird 
immer eine PLL aktiv sein müssen, die Schwankungen glättet. Das 
Spektrum, das sie dabei erzeugt, ist das Wesentliche dabei.

von Gerd E. (robberknight)


Lesenswert?

Warum hat es sich eigentlich nicht durchgesetzt, den Bittakt wie z.B. 
24,576MHz als Sinus auf Coax von zentraler Stelle aus an alle Geräte zu 
verteilen? So ähnlich wie die 10 MHz Referenztakt im HF-Labor, da klappt 
das doch auch gut.

Statt dessen wird im Studio Wordclock verteilt. Die ist aber so langsam 
daß ich wieder eine PLL nehmen muss um da den Bittakt draus zu erzeugen 
- und die erzeugt gleich wieder Jitter.

von Jobst M. (jobstens-de)


Lesenswert?

Gerd E. schrieb:
> daß ich wieder eine PLL nehmen muss um da den Bittakt draus zu erzeugen
> - und die erzeugt gleich wieder Jitter.

Nein, die Übertragung erzeugt Jitter.
Es ist die Frage, wie viel Aufwand (=Kosten) man in die PLL steckt, um 
den Jitter gering zu halten. Das ist bei einem festen Takt ein kleineres 
Problem, als bei einem Takt, den man erst aus einem Datenstrom fischen 
muss.
Es gibt PLL-Bausteine, die extra sehr Jitterarm sind. z.B. TI CDCE421

Gruß
Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Gerd E. schrieb:
> Warum hat es sich eigentlich nicht durchgesetzt, den Bittakt wie z.B.
> 24,576MHz als Sinus auf Coax von zentraler Stelle aus an alle Geräte zu
> verteilen?
Tja, das ist eine gute Frage, es liegt sicher an mehreren Gründen wie 
Anspruch auf Qualität und Kosten sowie das der Historie:

- Die ersten Soundkarten hatten zwar einen digitalen Ausgang, aber 
keinen Eingang. Die meisten Klangerzeuger der 90er haben ebenfalls einen 
Ausgang, aber keinen Synch-Eingang.

- Die meisten Mikrofone haben bis heute keinen digitalen Ausgang und 
wenn keinen der sich auf einen Referenz synchen lässt und in den wenigen 
Applikationen, in denen das geht, braucht es Spezialgeräte.

- Digital war lange im Studio als schlecht, kalt und unbrauchbar 
verpöhnt.

Daher gab es da auch wenig Bedarf für digitalen Synch.

Im Prinzip wird es so gemacht, wenn sich Digitalpulte und andere Geräte 
auf das Aufnahmegerät synchronisieren. Das ging schon mit DAT(48kHz) und 
klappt auch mit normalen Soundkarten.


> So ähnlich wie die 10 MHz Referenztakt im HF-Labor, da klappt
> das doch auch gut.
Der ist aber auch ein Zusatzsignal von dem aus höhere Raten abgeleitet 
werden müssen und PLLs eingesetzt werden - und dies schon deshalb, um 
nicht nur Störungen zu stabilisieren sondern vor Allem intern fein 
einstellbare Delays zu haben, um Laufzeiten zu kompensieren. Aus dem 
gleichen Grund braucht man oft auch eine PLL im Gerät.

Hinzu kommt, dass es mehrere Aufnahmetakte gab, nicht selten kamen 
Audiowandler mit krummen Frequenzen daher, die erst übersetzt werden 
mussten und es gibt ja 44,1 und 48,0 Systeme neben 32kHz etc. Eine PLL 
haben die Geräte also so oder so.

> Statt dessen wird im Studio Wordclock verteilt. Die ist aber so langsam
Das könnte auch an der Verfügbarkeit von Chips liegen: 25MHz über weite 
Strecken zu verteilen ist teurer und aufwändiger, als Audiotakte. Mithin 
müsste man bei einem Vielfachen auch ein Protokoll aufsetzen, welches 
das Nullbit ist, weil sonst wieder Synchronisation erfolgen muss. Also 
nimmt man eben gleich den word clock und erhält explizit den Wordtakt 
auf den sich das Gerät synchen kann und spart sich eine 
Frequenzberechnung.

> daß ich wieder eine PLL nehmen muss um da den Bittakt draus zu erzeugen
> - und die erzeugt gleich wieder Jitter.
Der ist egal, wenn die PLL im Empfänger sie ausgleicht. Es liegen ja 
Puffer auf beiden Seiten, die eine entsprechende Toleranz haben. Damit 
ist es möglich, auch sehr instabile Verbindungen zu betreiben, und die 
PLL weich zu stellen, sodas sie mitjittern kann und immer schon 1 bit 
liest, wenn eines geschrieben wird. Hochgenau und gut glättend ist da 
sogar kontraproduktiv oder man braucht zwei Pfade.

Direkte Verbindungen wie oben beschrieben verlieren dagegen schon mal 
den Takt, d.h. die PLL im Empfänger kommt aus dem Tritt. Einige 
Endgeräte, z.B. mein SPDIF-Mixer arbeiten daher vollkommen asynchron und 
Takten alles ein, in der Annahme, daß die Frequenzen stimmen. Dann 
braucht es eben einen einfach zu interpretierenden Takt.

Ich gebe Dir aber prinzipiell Recht und aus genau diesen Erwägungen 
heraus arbeite Ich ja auch hinsichtlich MIDI mit 25.x MHz. MIDI-Jitter 
ist noch heute das Problem in vielen Studios. Die Taktrate ist einfach 
zu gering und erlaubt nur eine grobe automatische Synchronisation.
Bei mir rasten die Units exakt aufs Bit 0 im S/PDIF Datenstrom ein und 
reagieren auf MIDI samplegenau.

von Gerd E. (robberknight)


Lesenswert?

Jobst M. schrieb:
> Nein, die Übertragung erzeugt Jitter.

Aber doch vor allem bei steilflankigen Digitalsignalen, weniger bei 
einem Sinus. Und bei S/PDIF kommt noch hinzu daß ich da ja Signal und 
Takt in einem übertrage und hinterher nicht beide optimal wieder 
rausbekomme.

Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel 
zu verlegen und darüber eine jitterarme Bitclock zu verteilen. Beim 
Empfänger brauche ich nur einen Komparator um die Clock wieder auf ein 
Digitalsignal zu bringen und dann ein Flipflop um das S/PDIF-Signal 
(oder vielleicht besser gar das daraus wieder regenerierte I2S) vom 
Jitter zu befreien.

> Es gibt PLL-Bausteine, die extra sehr Jitterarm sind. z.B. TI CDCE421

Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt 
einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt 
sich aber mit der Anforderung von geringer Latenz.

: Bearbeitet durch User
von Jobst M. (jobstens-de)


Lesenswert?

Gerd E. schrieb:
> Aber doch vor allem bei steilflankigen Digitalsignalen, weniger bei
> einem Sinus.

Wieso sollte eine Leitung einen Sinus anders behandeln?


> Und bei S/PDIF kommt noch hinzu daß ich da ja Signal und
> Takt in einem übertrage und hinterher nicht beide optimal wieder
> rausbekomme.

Natürlich bekommt man beides wieder sauber heraus. Man muss sich aber 
eben Mühe geben.

> Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel
> zu verlegen und darüber eine jitterarme Bitclock zu verteilen.

Naja, Du hast nicht als erster die Idee. Es gibt allerdings auch Leute, 
die übertragen den Bitclock vom Empfänger zum Sender.

> Beim
> Empfänger brauche ich nur einen Komparator um die Clock wieder auf ein
> Digitalsignal zu bringen

... und dort wieder Jitter zu haben ...

> und dann ein Flipflop um das S/PDIF-Signal
> (oder vielleicht besser gar das daraus wieder regenerierte I2S) vom
> Jitter zu befreien.

Dann brauchst Du erstmal wieder ... eine PLL.

>> Es gibt PLL-Bausteine, die extra sehr Jitterarm sind. z.B. TI CDCE421
>
> Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt
> einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt
> sich aber mit der Anforderung von geringer Latenz.

Ich habe noch nie einen Jitter bei SPDIF gesehen, der länger als ein 
halbes Bit war. Reicht also, wenn die PLL innerhalb eines Bits 'atmet'

Gruß
Jobst

von Gerd E. (robberknight)


Lesenswert?

Jobst M. schrieb:
> Wieso sollte eine Leitung einen Sinus anders behandeln?

Ein reiner Sinus hat nur die gewünschte Frequenz. Das scharfflankige 
Digitalsignal hat jede Menge Oberwellen deutlich darüber. Nicht optimale 
Terminierung oder Anpassung der Leitung wirken sich da viel stärker aus.

>> Und bei S/PDIF kommt noch hinzu daß ich da ja Signal und
>> Takt in einem übertrage und hinterher nicht beide optimal wieder
>> rausbekomme.
>
> Natürlich bekommt man beides wieder sauber heraus. Man muss sich aber
> eben Mühe geben.

So daß man das Signal interpretieren und die Clock in eine PLL werfen 
kann, ja. Aber direkt damit z.B. einen DAC füttern?

>> Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel
>> zu verlegen und darüber eine jitterarme Bitclock zu verteilen.
>
> Naja, Du hast nicht als erster die Idee. Es gibt allerdings auch Leute,
> die übertragen den Bitclock vom Empfänger zum Sender.

Ich behaupte nicht daß ich der erste bin der auf die Idee kommt. Gab 
glaube ich mal den Namen "Superclock" dafür. Ist aber definitiv nicht 
Standard. Ich frage mich jetzt halt warum, denn mir erscheint es 
sinnvoll.

>> Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt
>> einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt
>> sich aber mit der Anforderung von geringer Latenz.
>
> Ich habe noch nie einen Jitter bei SPDIF gesehen, der länger als ein
> halbes Bit war. Reicht also, wenn die PLL innerhalb eines Bits 'atmet'

Dann brauchst Du eine sehr schnell reagierende PLL. Deren Clock willst 
Du aber nicht auf einen DAC geben, denn dann hörst Du die Sprünge. Du 
bräuchtest eine langsam regelnde PLL und einen Puffer, der die Zeit 
ausgleicht in der die PLL langsam auf die Frequenz der Quelle wandert.

von Jobst M. (jobstens-de)


Lesenswert?

Gerd E. schrieb:
> Dann brauchst Du eine sehr schnell reagierende PLL.

Nein. Die empfangene Frequenz wandert ja nicht wild durch die Gegend, 
sondern ist im Mittel stabil. Und dort bleibt die PLL und regelt nur 
langsam dem Mittel hinterher. Das sind dann aber tatsächliche 
Frequenzänderungen!

Das bedeutet natürlich, dass der Lock-Vorgang länger dauert. Und erst 
wenn das passiert ist, gibt man Audio aus.

Gruß
Jobst

von Falk B. (falk)


Lesenswert?

@Gerd E. (robberknight)

>> Wieso sollte eine Leitung einen Sinus anders behandeln?

>Ein reiner Sinus hat nur die gewünschte Frequenz. Das scharfflankige
>Digitalsignal hat jede Menge Oberwellen deutlich darüber. Nicht optimale
>Terminierung oder Anpassung der Leitung wirken sich da viel stärker aus.

Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die 
ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung 
den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter).

>So daß man das Signal interpretieren und die Clock in eine PLL werfen
>kann, ja. Aber direkt damit z.B. einen DAC füttern?

Davon redet kein Mensch!


>> Ich habe noch nie einen Jitter bei SPDIF gesehen, der länger als ein
>> halbes Bit war. Reicht also, wenn die PLL innerhalb eines Bits 'atmet'

Eben.

>Dann brauchst Du eine sehr schnell reagierende PLL.

FALSCH!!! Es braucht 2 Dinge.

1. Clock and Data Recovery (CDR), die muss immer schnell sein und muss 
auch auf ggf. vorhandenen Jitter reagieren. Die schreibt ihre Daten in 
einen FIFO und liefert den zurückgewonnen, jitterbehafteten Takt (nicht 
clock!, Scheiß Denglisch!).

2. PLL. Die synchronisiert sich auf den zurückgewonnen, jitterbehafteten 
Takt und filtert mit einer SEHR geringen Bandbreite (Schleifenfilter) 
eben diesen, sodaß (hochfrequenter) Jitter entfernt wird. Mit diesem 
Takt wird das FIFO gelesen und der DAC betrieben.

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

Falk B. schrieb:
> Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die
> ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung
> den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter).

Naja, eine Störung kann ja durchaus lang genug sein um 10 Taktflanken zu 
treffen. Das Problem ist einfach der kleine Hub der im Signal steckt. 
Bei einem steilen dU/dt macht der weniger aus, weil Ich das 
Eingangsfilter für diesen Takt entsprechend auf HF auslegen kann. Ist im 
Prinzip wie beim Oszilloskop der HF-Trigger. Damit würde ein Sinus nur 
schlecht funktionieren.

Trotzdem hat Gerd nicht ganz Unrecht, denn:

Gerd E. schrieb:
> Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel
> zu verlegen und darüber eine jitterarme Bitclock zu verteilen.
Es ist in der Tat so, dass es einfacher ist, einen jitterarmen Sinus zu 
produzieren und den zu verteilen, als Rechtecksignale, wenn es nur um 
einen Takt geht, denn die PLL könnte sich genau auf diese Frequenz 
konzentieren. Zudem erzeugen steile Signale eben auch andere Probleme, 
wie Reflektionen, die dann den Takt wieder verbiegen. Die Qualität einer 
Sinusverbindung ist letztlich höher. Es wäre aber in der Tat dann ein 
Extratakt. Liefe im Prinzip auf das Synchen auf die DCF77 Atomuhr 
hinaus: Ganz langsam filtern.

Den Aufwand will man halt nicht treiben und vor allem keine Extrakabel.

> Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt
> einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt
> sich aber mit der Anforderung von geringer Latenz.
Nicht, wenn man das parallel macht:

Falk B. schrieb:
> 1. Clock and Data Recovery (CDR), die muss immer schnell sein und muss
> 2. PLL. Die synchronisiert sich auf den zurückgewonnen, jitterbehafteten
Ja, exakt so.

Die Chips machen das, fressen vorne so ziemlich alles und sind bis auf 
Viertel-Bits genau. Trotz ordentlicher PLL kriegen sie aber den Takt 
nicht beliebig gut hin, weil S/PDIF eben auch stark niederfrequente 
Anteile hat, nicht zuletzt weil der Sender oft von mässiger Qualität 
ist. Aus vielen Geräten, die beides zur Verfügung stellen, bekommt man 
das gleiche logische Signal über die AES/EBU Buchse erheblich besser 
angeliefert.

von Falk B. (falk)


Lesenswert?

@Jürgen S. (engineer)

>> Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die
>> ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung
>> den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter).

>Naja, eine Störung kann ja durchaus lang genug sein um 10 Taktflanken zu
>treffen.

Kann sein, ändert aber nichts am Grundproblem.

>> Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel
>> zu verlegen und darüber eine jitterarme Bitclock zu verteilen.

>Es ist in der Tat so, dass es einfacher ist, einen jitterarmen Sinus zu
>produzieren und den zu verteilen, als Rechtecksignale,

Naja.

> wenn es nur um
>einen Takt geht, denn die PLL könnte sich genau auf diese Frequenz
>konzentieren.

Das kann sie auch mit einem Rechtecksignal!

>Zudem erzeugen steile Signale eben auch andere Probleme,
>wie Reflektionen, die dann den Takt wieder verbiegen.

Auch das ist ein lösbares Problem. Die Terminierung von HF-Leitungen ist 
schon erfunden.

> Die Qualität einer Sinusverbindung ist letztlich höher.

Jaja, wenn es ein Physiker unter quantenmechanischen Bedingungen 
betrachtet. Dein Sinus muss aber am Empfänger wieder in ein Rechteck 
gewandelt werden.

> Es wäre aber in der Tat dann ein
>Extratakt. Liefe im Prinzip auf das Synchen auf die DCF77 Atomuhr
>hinaus: Ganz langsam filtern.

Kann man auch mit einer PLL.

>Den Aufwand will man halt nicht treiben und vor allem keine Extrakabel.

Eben.

>> Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt
>> einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt
>> sich aber mit der Anforderung von geringer Latenz.

>Nicht, wenn man das parallel macht:

Man kann nicht alles parallel machen.

>Die Chips machen das, fressen vorne so ziemlich alles und sind bis auf
>Viertel-Bits genau. Trotz ordentlicher PLL kriegen sie aber den Takt
>nicht beliebig gut hin, weil S/PDIF eben auch stark niederfrequente
>Anteile hat,

Wo kommen die her? Hat nicht jeder S/PDIF Sender einen Quarzoszillator, 
welcher auch die Sendeendstufe taktet? Klar, man kann auch einen 
vergurkten Quarzoszillator bauen, der niederfrequent jittert (aka 
Wander).

> nicht zuletzt weil der Sender oft von mässiger Qualität
>ist. Aus vielen Geräten, die beides zur Verfügung stellen, bekommt man
>das gleiche logische Signal über die AES/EBU Buchse erheblich besser
>angeliefert.

Wieso? Die Taktquelle ist doch die gleiche?

von Gerd E. (robberknight)


Lesenswert?

Falk B. schrieb:
>>Ein reiner Sinus hat nur die gewünschte Frequenz. Das scharfflankige
>>Digitalsignal hat jede Menge Oberwellen deutlich darüber. Nicht optimale
>>Terminierung oder Anpassung der Leitung wirken sich da viel stärker aus.
>
> Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die
> ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung
> den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter).

Am Empfänger kannst Du bei einem Sinussignal einen steilen 
Bandpassfilter verwenden, der die Störungen auf anderen Frequenzen sehr 
deutlich dämpft. Bei einem Rechteck geht das nicht, da kannst Du 
höchstens einen Hochpass einbauen.

Warum verwendet man wohl bei der klassischen 10MHz-Laborreferenz auch 
Sinus und kein Rechteck?

> 2. PLL. Die synchronisiert sich auf den zurückgewonnen, jitterbehafteten
> Takt und filtert mit einer SEHR geringen Bandbreite (Schleifenfilter)
> eben diesen, sodaß (hochfrequenter) Jitter entfernt wird. Mit diesem
> Takt wird das FIFO gelesen und der DAC betrieben.

Da hast Du wieder den FIFO der zusätzliche Latenz hinzufügt.

Wenn man wirklich rausholen möchte, was mit verfügbaren Komponenten 
möglich ist, bleibt die Frage womit man weniger Jitter hinbekommt: mit 
einem Komparator aus dem gut gefilterten Sinus oder mit einer PLL. Und 
ob man den für die PLL nötigen FIFO mit seiner Latenz akzeptieren kann.

Aber warum sich das im Studioumfeld nicht durchgesetzt hat, hat denke 
ich Jürgen beantwortet:

Jürgen S. schrieb:
> Den Aufwand will man halt nicht treiben und vor allem keine Extrakabel.

von J. S. (engineer) Benutzerseite


Lesenswert?

Falk B. schrieb:
>>Naja, eine Störung kann ja durchaus lang genug sein um 10 Taktflanken zu
>>treffen.
> Kann sein, ändert aber nichts am Grundproblem.
Das Grundproblem ist nicht, wie viele meinen, dass etwaige Störungen 
eine Flanke zertören. Das würde eine PLL "überlesen".
Das Problem ist, dass durchaus geringe Störungen niederfrequenter Art 
einen Hub auf das Signal machen und den Schaltzeitpunkt verschieben.
Dem geht der PLL hinterher und kann das nicht filtern.


>>Es ist in der Tat so, dass es einfacher ist, einen jitterarmen Sinus zu
>>produzieren und den zu verteilen, als Rechtecksignale,
> Naja.
Ja. Ist so. Haben wir bei einem ganz konkreten Projekt im Bereich TDC 
genauestens untersucht.

>> wenn es nur um
>>einen Takt geht, denn die PLL könnte sich genau auf diese Frequenz
>>konzentieren.
> Das kann sie auch mit einem Rechtecksignal!
Das ist erstens nicht ganz so trivial und zweitens kommt kein Rechteck 
an. Das ist das Problem.


>>Zudem erzeugen steile Signale eben auch andere Probleme,
>>wie Reflektionen, die dann den Takt wieder verbiegen.
> Auch das ist ein lösbares Problem. Die Terminierung von HF-Leitungen ist
> schon erfunden.
Du hast doch sicher Erfahrungen, wie 100% Terminierungen wirken, oder ? 
:-)


>> Es wäre aber in der Tat dann ein
>>Extratakt. Liefe im Prinzip auf das Synchen auf die DCF77 Atomuhr
>>hinaus: Ganz langsam filtern.
> Kann man auch mit einer PLL.
Nicht "kann man" sondern "muss man".
Es ging darum, ob eine PLL so träge sein kann, dass sie sehr gut filtern 
kann und trotzdem den Takt nicht an den Daten vorbeiregelt.
Und das ist, wie schon erörtert kein Problem, weil Taktrückgewinnung zur 
Weiterverarbeitung - sowie Einlesen der Daten mit dem lokalen jitternden 
Takt sich nicht widersprechen.


>>Nicht, wenn man das parallel macht:
> Man kann nicht alles parallel machen.
Mit "parallel" meinte Ich genau den Satz obendrüber, der Deiner 
Erklärung vom Beitrag weiter oben entspricht:
1. Schnelle PLL zur Interpreation des Bits
2. Langsame PLL zur Erzeugung eines internen Taktes

>>Die Chips machen das, fressen vorne so ziemlich alles und sind bis auf
>>Viertel-Bits genau. Trotz ordentlicher PLL kriegen sie aber den Takt
>>nicht beliebig gut hin, weil S/PDIF eben auch stark niederfrequente
>>Anteile hat,
>
> Wo kommen die her? Hat nicht jeder S/PDIF Sender einen Quarzoszillator,
Von 1. der Quelle und 2. der Leitung.
Sicher hat jeder seinen Taktgenerator, aber auch der ist
a) nicht 100% stabil und muss sich gfs ...
b) auf einen externen Takt synchen, hoppelt also um eine Vorgabe herum.


>> Aus vielen Geräten, die beides zur Verfügung stellen, bekommt man
>>das gleiche logische Signal über die AES/EBU Buchse erheblich besser
>>angeliefert.
> Wieso? Die Taktquelle ist doch die gleiche?

Ja, aber die Leitungsqualtität ist bei symmetrischer Signalführung eben 
besser, es kommt also weniger zusätzlicher Jitter rein.

Die gesamte Frage ist also weniger, OB es geht, sondern immer WIE GUT es 
geht. Und bei S/PDIF kann man den Jitter bei schlechten Geräten und 
Verbindungen durchaus hören. Das bestreiten manche, ist aber so.

von J. S. (engineer) Benutzerseite


Lesenswert?

Ah, da war jemand schneller:

Gerd E. schrieb:
> Warum verwendet man wohl bei der klassischen 10MHz-Laborreferenz auch
> Sinus und kein Rechteck?
Wie oben schon festgestellt, weil die Filterung mit weniger Aufwand zu 
erledigen - und ein besseres Ergebnis zu erzielen ist. Das geht vor 
allem auch Analog noch sehr gut. Natürlich kann man das auch digital 
machen und da ist der Aufwand hin zu einer Rechteckprozessierung nicht 
viel höher - aber es gibt auf Leitungen eben kein Rechteck. Man muss 
also immer irgend eine Annahme über die Anstiegszeit machen. Das macht 
es dann letztlich nicht besser.

> Da hast Du wieder den FIFO der zusätzliche Latenz hinzufügt.
Den braucht man aber, weil der das Problem löst. Praktisch sind das aber 
nur ein paar Bits, weil die tieffrequenten Gleichlaufschwankungen, die 
sich durch Jitter ergeben, im Bereich von Promille bleiben. Und ein paar 
bits sind bei digitalen Audio im Grunde Null, weil erst 64 ein volles 
Stereosample ergeben.

Der Fifo ist kein Problem. Digitale Audiogeräte haben Latenzen im 
Bereich von etlichen Samples, selbst wenn sie ein Signal nur 
durchreichen.

> Wenn man wirklich rausholen möchte, was mit verfügbaren Komponenten
> möglich ist, bleibt die Frage womit man weniger Jitter hinbekommt: mit
> einem Komparator aus dem gut gefilterten Sinus oder mit einer PLL.
Bei den Meisten liegt kein ausreichendes Detailverständnis vor, daher 
nutzen viele im Studio nicht mal word clock.

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

@Gerd E. (robberknight)

>Am Empfänger kannst Du bei einem Sinussignal einen steilen
>Bandpassfilter verwenden, der die Störungen auf anderen Frequenzen sehr
>deutlich dämpft. Bei einem Rechteck geht das nicht, da kannst Du
>höchstens einen Hochpass einbauen.

OK.

>> eben diesen, sodaß (hochfrequenter) Jitter entfernt wird. Mit diesem
>> Takt wird das FIFO gelesen und der DAC betrieben.

>Da hast Du wieder den FIFO der zusätzliche Latenz hinzufügt.

Wir reden hier über wenige Bits, also unterhalb einer Samplezeit!

von J. S. (engineer) Benutzerseite


Lesenswert?

Vielleicht noch ein Nachtrag zum Eingangspost: Auch wenn es nicht ganz 
offiziell ist, inzwischen wird S/PDIF mit 384kHz (25 MHz) rausgeblasen, 
boardintern auf meiner Platine sogar mit 768kHz -> 50MHz.

Das Problem ist, es über längere Strecken zu übertragen. Gelungen ist 
das bisher nur mit einem Coax über knapp 1m. Optisch gibt es da keine 
Treiber für, zumindest nicht im klassischen TOSLINK-Glasfaserstandard.

von Falk B. (falk)


Lesenswert?

@Jürgen S. (engineer)

>offiziell ist, inzwischen wird S/PDIF mit 384kHz (25 MHz) rausgeblasen,
>boardintern auf meiner Platine sogar mit 768kHz -> 50MHz.

Muss man es immer übertreiben? Höher, schneller, weiter? Wo bleibt die 
Cleverness?

>Das Problem ist, es über längere Strecken zu übertragen. Gelungen ist
>das bisher nur mit einem Coax über knapp 1m. Optisch gibt es da keine
>Treiber für, zumindest nicht im klassischen TOSLINK-Glasfaserstandard.

TOSLINK hat keine GLASfaser, bestenfalls Lichtwellenleiter aus Plastik, 
aka POF (plastic optical fibre). ;-)

von J. S. (engineer) Benutzerseite


Lesenswert?

Falk B. schrieb:
> Muss man es immer übertreiben? Höher, schneller, weiter?
Was die Bandbreite angeht, kann es eigentlich nicht hoch genug sein, 
weil man ja auch die Zahl der Kanäle erhöhen kann. ADAT z.B. überträgt 
über ein optisches Kabel standardmäßig 8x48kHz oder 4x96 und was den 
Einwurf von MIDI über S/PDIF angeht, sind  auch da mehr Kanäle möglich, 
z.B. mehrere Dutzende Tastenänderungen (Orchester-Arrangement) mitsamt 
Parametern deutlich unter 1ms, also praktisch gleichzeitig, während mit 
normalem MIDI gerade 1 Note+Paramter übertragen wird.

> Wo bleibt die Cleverness?
In meinem Fall ist das Hochtreiben auch ein wenig der Historie 
geschuldet. Ich habe damals mit S/PDIF angefangen, Audio-Module zu 
verschalten und das der Einfachheit immer beibehalten. Würde Ich es 
heute nochmal neu ansetzen, würde Ich gfs was anderes nehmen. Zumindest 
in Richtung PC geht mit USB2.0 mehr, allerdings mit mehr Latenz: Das 
S/PDIF ist auf den ersten Blick ein etwas unnötig kompliziertes 
Protokoll, bringt aber nach 1/64 der Taktfrequenz das erste Doppeldatum 
in die Senke. Gerade bei den hohen Taktfrequenzen ist das serielle 
Protokoll sogar ein Vorteil.

> TOSLINK hat keine GLASfaser, bestenfalls Lichtwellenleiter aus Plastik,
> aka POF (plastic optical fibre). ;-)
Das ist richtig, allerdings gibt es (oder gab es) im Profibereich auch 
Glasfaserübertragung für MIDI und Audio, wenn es um Distanzen geht.

Die Plastikoptik, wenn man sie so nennen darf, ist auch in der Tat nicht 
so 100% betriebsstabil.

von Gerd E. (robberknight)


Lesenswert?

Jürgen S. schrieb:
> inzwischen wird S/PDIF mit 384kHz (25 MHz) rausgeblasen,
> boardintern auf meiner Platine sogar mit 768kHz -> 50MHz.
>
> Das Problem ist, es über längere Strecken zu übertragen. Gelungen ist
> das bisher nur mit einem Coax über knapp 1m.

1m ist ja jetzt nicht mal eine "kürzere Strecke", das reicht nicht mal 
von ganz unten im Rack bis oben. Ein eindeutiges Zeichen daß das 
Protokoll dafür nicht mehr passt.

Auf Kupferbasis müsste man wohl einen anderen Leitungscodec verwenden, 
so ähnlich wie bei Ethernet.

> Optisch gibt es da keine
> Treiber für, zumindest nicht im klassischen TOSLINK-Glasfaserstandard.

Bei den Geschwindigkeiten kannst Du PoF dann auch vergessen.

Unter Preis/Verfügbarkeitsgesichtspunkten würde es vermutlich Sinn 
machen SFP-Slots zu verwenden, wie sie an Ethernet-Switchen gängig sind. 
Da bekommt man z.B. für 20-30 EUR ein SX-Modul. Damit kann man dann 1 
GBit/s auf Multimode-Glasfaser übertragen, es sind Strecken bis 500m 
möglich. Für kürzere Strecken (und hier meine ich hier bis vielleicht 
50m) gibt es fertige Patchkabel mit LC-Buchsen für wenige Euro.

Wenn man mehr braucht, steckt man halt in den selben Slot ein LX-Modul 
rein und kommt dann mit Monomode-Fasern bis 10km weit.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Gerd E. schrieb:
> Ein eindeutiges Zeichen daß das
> Protokoll dafür nicht mehr passt.

Na, lass das mal nicht die SDI-Equipment Hersteller hoeren; die machen 
12GBit/sec ueber 75 Ohm Koax...
z.B.:
http://semtech.com/broadcast-video/configurable-eq-cd/gs12090/


Gruss
WK

von Gerd E. (robberknight)


Lesenswert?

Dergute W. schrieb:
>> Ein eindeutiges Zeichen daß das
>> Protokoll dafür nicht mehr passt.
>
> Na, lass das mal nicht die SDI-Equipment Hersteller hoeren; die machen
> 12GBit/sec ueber 75 Ohm Koax...

Aber ist das denn der selbe Biphase Mark Code wie bei S/PDIF?

Wenn man sich mit mehreren Trägern, QAMsoundsoviel etc. austobt, bekommt 
man ohne Probleme ein paar GBit über Koax, siehe z.B. Kabelfernsehen. 
Genau das meinte ich damit, daß das Protokoll nicht mehr passt.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Lesenswert?

Moin,

Gerd E. schrieb:
> Aber ist das denn der selbe Biphase Mark Code wie bei S/PDIF?

Natuerlich nicht. Aber es ist ein NRZI - also auch stumpf Einser und 
Nuller als 2 verschiedene Spannungen (0 und 800mV) ueber's Kabel 
getackert.

> Wenn man sich mit mehreren Trägern, QAMsoundsoviel etc. austobt, bekommt
> man ohne Probleme ein paar GBit über Koax, siehe z.B. Kabelfernsehen.

Ist schon klar. Aber genau deshalb hab' ich SDI als Beispiel genommen 
und eben nicht Kabelfernsehen oder irgendwelches 
Ethernet-over-Powerline-Gedoens.

Gruss
WK

von J. S. (engineer) Benutzerseite


Lesenswert?

Gerd E. schrieb:
> Auf Kupferbasis müsste man wohl einen anderen Leitungscodec verwenden,
> so ähnlich wie bei Ethernet.

Ja, das ist wohl war. Mit dem einfachen BMC ist das Ende der 
Fahnenstange wohl erreicht.


Dergute W. schrieb:
> Wenn man sich mit mehreren Trägern, QAMsoundsoviel etc. austobt, bekommt
> man ohne Probleme ein paar GBit über Koax, siehe z.B. Kabelfernsehen.
> Genau das meinte ich damit, daß das Protokoll nicht mehr passt.

Das ist halt eine andere Hausnummer, inklusive Echokompensation.
Eigentlich müsste man alle Geräte auf Ethernet umstellen und mit Phys 
ausstatten, aber wer will das tun?

von A. F. (chefdesigner)


Lesenswert?

Ich habe mir nun die letzten Beiträge der vergangen Monate durchgelesen 
und die Argumente pro und contra Rechteck <-> Sinus durchgegelesen. Ich 
halte es nach wie vor für offen, ob es zweckmässiger ist einen Takt als 
Sinus oder Rechteck zu übertragen. Rechteck auf der Grundwelle scheint 
mit informationsreicher, als die Sinuswelle. Auf der anderen Seite kann 
die Sinuswelle auf der höchsten Frequenz der Oberwelle des Rechtecks 
laufen, die gerade noch übertragen werden kann.

Was also ist besser?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.