Forum: Digitale Signalverarbeitung / DSP / Machine Learning 2x SPDIF an ADAU1701


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 F. (zwanni)


Lesenswert?

Hallo,

ich plane an einem einfachen Audiomischer mit dem ich zwei SPDIF 
(Toslink) Signale beliebig auf 2 Stereo Ausgänge mischen kann. Habe das 
Ganze mal analog probiert, wurde mir aber zu aufwendig. Zumindest denke 
ich mittlerweile, dass es Digital fast einfacher ist und Probleme wie 
Masseschleifen und digital gesteuertes analog-mischen wegfallen.

Von DSP habe ich bis jetzt keine Ahnung, aber da es zum ADAU1701 viele 
Beispiele gibt halte ich das Projekt für umsetzbar. Zur SPDIF 
Decodierung auf I²S wollte ich 2 CS8416 nehmen. Dafür findet man ebenso 
genügend Beispiele. In der Theorie lässt sich dann mit Sigma Studio sehr 
einfach der Mischer verknüpfen und 4 analoge Ausgänge sind auch 
vorhanden.

Was ich aktuell nicht verstehe ist wie ich 2 I²S Ströme in den ADAU1701 
bekomme. Der hat zwar 4 Digitale Eingänge aber nur einmal "INPUT_LRCLK" 
und "INPUT_BCLK".
Ist es möglich den ADAU1701 über MP10 und MP11 (OUTPUT_LRCLK / 
OUTPUT_BCLK) als Master für die beiden CS8416 zu nutzen und diese dann 
Parallel an den beiden Leitungen zu betreiben?

von Georg A. (georga)


Lesenswert?

Digital via SPDIF ist das nicht so einfach, wie du denkst. Damit das im 
DSP geht, müssen beide Signal-Quellen synchron sein, sonst gibts 
verdoppelte/ausgefallene Samples. Klingt jetzt nicht so schlimm, ist 
aber durchaus hörbar. Damit ist ein Resampling auf einen gemeinsamen 
Takt notwendig. Das wäre auch noch einfach, wenn der Versatz der 
Samplefrequenzen bekannt wäre. Ist er aber nicht, kommt ja von 
sonstwoher. Also muss das on-the-fly anhand von Buffer-Füllständen mit 
etwas Regelung dahinter berechnet werden. Das wird dann schon etwas 
anspruchsvoller. Gibt dafür aber auch fertige Chips (AD1896 etc).

Mit zwei AD-Wandlern wird der ganze Mist unsichtbar schon auf der 
analogen Seite gemacht, wird also viel einfacher ;)

von Paul F. (zwanni)


Lesenswert?

okay, wäre es dann eine Option einen Eingang Digital per SPDIF und einen 
analog einzuspeisen? Analog wäre ja ohnehin nur ein Stereo Eingang 
verfügbar. Dann wären ja sowohl meine Frage als auch das Sampling 
Problem gelöst oder?

Es sind keine High-End Anforderungen. Ich will meinen PC und einen 
Android Rechner auf Headset und Lautsprecher mischen können. Das beide 
Signale vermischt werden ist wohl eher die Ausnahme wäre aber gut.

von Georg A. (georga)


Lesenswert?

> okay, wäre es dann eine Option einen Eingang Digital per SPDIF und
> einen analog einzuspeisen?

Das geht, wenn du bei Ausfall des SPDIF-Taktes für den ADC auf einen 
internen (Master-Clock) umstellst. Ansonsten kommt der Takt vom 
SPDIF-Chip und der ADC hängt immer als Slave dran.

> Es sind keine High-End Anforderungen.

Das "überraschende" an dem Synchronitätsproblem ist ja, dass es zwar 
vernachlässigbar klingt (ein fehlendes/verdoppeltes Sample hört doch 
keiner...), es aber auch ohne goldene Ohren problemlos hörbar ist 
(leises Knacksen zB. im Sekundentakt je nach Abweichung der Takte).

Aus dem Resampling-Grund gibts ja im Profi-Umfeld einen 
Masterclock/Wordclock-Eingang für alle SPDIF-Quellen. Dann braucht man 
keinen Resampler. Aber halt noch eim Kabel, was man überall rumführen 
muss...

von Paul F. (zwanni)


Lesenswert?

Georg A. schrieb:
> Das geht, wenn du bei Ausfall des SPDIF-Taktes für den ADC auf einen
> internen (Master-Clock) umstellst. Ansonsten kommt der Takt vom
> SPDIF-Chip und der ADC hängt immer als Slave dran.

Was bedeutet das in der Praxis? Wenn kein Signal am SPDIF anliegt, gibt 
es keinen Takt und man muss dem ADAU1701 sagen, dass er den internen 
Takt nutzen muss. Oder passiert das automatisch?

Georg A. schrieb:
> Aus dem Resampling-Grund gibts ja im Profi-Umfeld einen
> Masterclock/Wordclock-Eingang für alle SPDIF-Quellen. Dann braucht man
> keinen Resampler. Aber halt noch eim Kabel, was man überall rumführen
> muss...

Das war ja die Ausgangsfrage: Ob der ADAU1701 den Master für zwei CS8416 
geben kann. Der CS8416 kann laut Datenblatt auf jeden Fall als slave 
arbeiten. Ob der Ausgabetakt vom ADAU1701 nur für die Ausgänge ist oder 
auch für Eingänge benutzt werden kann konnte ich nicht rauslesen.

von Georg A. (georga)


Lesenswert?

> Der CS8416 kann laut Datenblatt auf jeden Fall als slave arbeiten.

Ja, aber das bezieht sich auf Bit und Wordclock, d.h. die sind Eingänge 
in den CS8416. Aber so oder so müssen die von RMCK abgeleitet sein, 
entweder im CS8416 als Master, oder im ADAU als Master. Im Prinzip ist 
das Master/Slave-Ding nur die Frage, wo die Teiler für SCLK und LRCLK 
aus dem Basistakt sitzen.

> Was bedeutet das in der Praxis? Wenn kein Signal am SPDIF anliegt, gibt
> es keinen Takt und man muss dem ADAU1701 sagen, dass er den internen
> Takt nutzen muss. Oder passiert das automatisch?

Keine Ahnung, ob der ADAU das kann. Dafür könnte aber man OMCK vom 
CS8416 nutzen, ist genau für sowas da. Wenn da der Default-Clk zB. von 
einem 48kHz*256-Quarz (oder *512, je nach Setup) reinkommt, kommt der am 
RMCK im Falles eines fehlenden SPDIF-Signals wieder raus. D.h. das ganze 
ADAU-Zeug läuft erstmal mit RMCK. Ob der ADAU jetzt I2S-Master oder 
Slave ist, ist da IMO egal, der ADC muss auf jeden Fall Slave sein.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Georg A. schrieb:
> Damit ist ein Resampling auf einen gemeinsamen
> Takt notwendig

Dann braucht man aber auch kein resampling (?) - oder meintest Du was 
anderes?

Ich habe einen VHDL-basierten Resampler über Taktdomänen hinweg, der 
kann am Eingang alles fressen, was kommt und arbeitet mit seinem 
Abholtakt. Qualität rund 100dB sfdr. Den Jitter kann man mit einer PLL 
kontrollieren, wenn man will. Geht für 16 Takte in einem Spartan 3E 
FPGA. Ausgabe über insgesamt 4 I2S-ähnliche Schnittstellen. Man halt 
also direkt eine Matrix.

Allerdings lohnt das nur, wenn man das Audio auch intern verarbeiten 
will. Nur Mischen geht analog einfacher und besser. Also die Eingänge 
über DAC auf einen R-R-Netzwerk und dann rein in den Ausgangs-ADC, 
sofern man den überhaupt noch braucht. Wird im Studio inzwischen auch 
wieder so gemacht.

: Bearbeitet durch User
von Georg A. (georga)


Lesenswert?

> Dann braucht man aber auch kein resampling (?) - oder meintest
> Du was anderes?

Man wählt sich einen Takt (entweder einen der Eingangstakte oder einen 
ganz eigenen) und resampled einen bzw. beide Eingangsdaten darauf. Was 
meinst du denn? ;)

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Hallo, Ich hatte das etwas anders gelesen, als Du es wahrscheinlich 
gemeint hast, weil Du die Sätze direkt aneinander geheftet hattest, so 
als sei Satz 2 die Folge des ersten:

>Synchron sein ...
>damit braucht man ein resampling

(denn, wenn sie synchron wären, brächte man eben kein resampling)

Aber da sie ja nicht synchron sind, braucht es das resampling. Damit 
hätten wir es.

Was wir aber noch nicht hätten:

Manuell resampeln oder es den Chip machen lassen:

Ich persönlich habe eine Lösung, daher manuell im FPGA. Der Anfänger 
sollte einen Chip nehmen. Das zu programmieren ist kein Kinderspiel.

Es gibt übrigens in der Bucht immer mal wieder einen gebrauchten 
Digitalmixer, die das teilweise auch ganz leidlich können. Von meinem 
eigenen mal abgesehen :-(

von Paul F. (zwanzischmark)


Angehängte Dateien:

Lesenswert?

da bin ich wieder...

noch einmal kurz Zusammengefasst:
ADAU1701 DSP mit einem analogen Stereo Eingang und einem über DIR9001 
decodierten SPDIF Signal als I2S.
Zwei Stereo Ausgänge, direkt analog aus dem ADAU1701.

Hab es endlich geschafft das Projekt voran zu bringen. 
Erstaunlicherweise funktionierte direkt alles fast perfekt. Habe doch 
einen DIR9001 zur SPDIF Decodierung eingesetzt. Den zweiten Eingang 
entsprechend analog. Die Audioqualität ist für meine Zwecke super und 
Mischen/Verteilen der beiden Signale auf zwei Ausgänge klappt auch 
perfekt.
Einziges Problem sind Mikroruckler/Sampleverluste? die auch nicht 
regelmäßig auftreten. Woran könnte das liegen?

Samplingproblem?
PLL verlust beim DIR9001?
Noch irgendein Einstellungsproblem zwischen DIR9001 und ADAU1701?
Konfiguration des ADAU1701 falsch?
...?

Mit höherer Samplerate wird es schlimmer.

Jemand Ideen?

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Wo und an welches Stelle entstehen die "Ruckler"?

Wer ist Master in Deinem System? Die Converterchips synchen sich ja bei 
Bedarf auf das eingehende S/PDIF und erzeugen MCLK, das Datensignal und 
gfs noch eine 64-fache Clock. An die musst Du dich dranhängen.

von Paul F. (zwanzischmark)


Lesenswert?

Ich weiß leider nicht an welcher Stelle es hängt...

Der DIR9001 erzeugt im Normalzustand den Takt aus dem S/PDIF Signal und 
gibt diesen an den ADAU1701 weiter.

Wenn ich das Toslink Kabel abziehe schaltet der DIR9001 auf den vom 
Quarz erzeugten Takt um. Beim ADAU1701 muss dann I2S deaktiviert sein, 
dann läuft auch der weiter. In der Theorie also alles so wie es sein 
soll.

Ich weiß leider nicht wie ich Fehler außer mit dem Ohr erkennen kann. 
Teilweise ist das gar nicht so leicht wahrzunehmen. Kann nur vermuten, 
dass es direkt am DIR9001 hakt, oder der ADAU1701 sich irgendwann 
verschluckt. Die Abstände wo man was hört sind schon meist mehr als ein 
paar Sekunden.

: Bearbeitet durch User
von Paul F. (zwanzischmark)


Lesenswert?

Habe nochmal versucht Dinge Auszuschließen

- Wenn ich den Toslink abziehe und über den analogen Eingang höre ist 
alles sauber. (dann kommt der Takt auch vom DIR9001, aber vom externen 
Oszillator)

- Sobald der Takt vom S/PDIF Signal kommt habe ich die "Fehler" auch 
über den analogen Eingang.

Das Problem entsteht also wenn der DIR9001 den Takt aus dem S/PDIF 
zieht, bzw. der ADAU1701 den Takt über das I2S bekommt.

Eventuell habe ich da irgendwas nicht richtig eingestellt.

Am DIR9001 kann ich die PLL source einstellen (128fS, 256fS, 384fS, 
512fS)

und am ADAU1701 kann ich PLL_Mode einstellen (64fS, 256fS, 384fS, 512fS)

Den ADAU1701 kann ich meines erachtens nicht auf slave umstellen. Das 
scheint automatisch zu passieren, sobald ich I2S im ADAU1701 
konfiguriere, oder habe ich da etwas übersehen?

Laut Datenblatt ist der ADAU1701 auf 256xfs designt, deshalb war das 
auch meine Zielkonfiguration. Ich habe aber auch andere Konfigurationen 
ausprobiert, es verändert aber lediglich das Fehlergeräusch.

Noch irgendwelche Ideen?

Edit:
würde nun fast auf PLL Fehler vermuten, weil es auch unzyklisch 
auftritt, wüsste aber nicht was ich daran verbessern kann.

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


Lesenswert?

S/PDIF optisch macht manchmal Probleme mit schlechten TOSLINK-Buchsen. 
Ich glaube aber eher, dass es hier einfach ein Synch-Problem ist. Wenn 
der ADU den Takt aus dem Chip bezieht, müsste man den mal messen. Gfs 
ist eine geringere Auflösung besser, da der Takt ja erst aus dem S/PDIF 
rekonstruiert werden muss und "netto" da nur das 64-fache des 
Datentaktes drin steckt.

von Paul F. (zwanzischmark)


Lesenswert?

Du meinst Sync vom S/PDIF selbst? Das meinte ich eigentlich auch, 
vielleicht hab ichs nicht fachgerecht formuliert.
Da müsste ich allgemein mal mit nem Oszi dran, wie sauber das Signal da 
aussieht. Hab ich aber im Moment leider nicht.
Prinzipiell trifft das aber zu was du sagst. Wenn ich mit der Samplerate 
hochgehe, geht es quasi gar nicht mehr.

Ohne Oszi wird ich hier wohl nicht weiter kommen, also erstmal pausieren 
:D

danke trotzdem erstmal

von Hi-Tech-Progger S. (Gast)


Lesenswert?

Eine kleine Zwischenfrage: Wie soll denn bitteschön die Synchronisation 
zwischen den beiden Eingängen laufen? Die haben ja ihr eigenes 
S/PDIF-Signal und das weicht sicher leicht ab.

von Paul F. (zwanzischmark)


Lesenswert?

Es gibt keine 2 S/PDIF Eingänge, der zweite ist analog. Der Plan war 
ursprünglich das ganze mit zwei Digitalen Eingängen zu bauen, daher ist 
der Titel vom Beitrag noch so. Mir wurde ja dann gleich gesagt, dass die 
beiden Signale dann synchron sein müssen. Das wurde mir dann für mein 
erstes Projekt dieser Art dann doch zu haarig.

: Bearbeitet durch User
von Thomas F. (tf1973)


Lesenswert?

Paul F. schrieb:

> Den ADAU1701 kann ich meines erachtens nicht auf slave umstellen. Das
> scheint automatisch zu passieren, sobald ich I2S im ADAU1701
> konfiguriere, oder habe ich da etwas übersehen?

Wenn du MP4 und MP5 als Clock Eingänge verwendest arbeitet der ADAU1701 
ausschließlich als Slave. Wenn du ihn im Master Mode betreiben willst 
mußt du die Clock Ausgänge mit den Clock Eingängen verbinden, also MP10 
mit MP4 und MP11 mit MP5. Die Clock Leitungen sind dann für deinen 
DIR9001 zuständig und gleichzeitig intern. Keine Ahnung warum die 
Verbindung nicht intern mit Register gesetzt werden kann - ist eben so 
:-) Auch nochmal auf S.46 im Datenblatt beschrieben.

Ansonsten kommst du wohl nicht um den Oszi herum, die Clock Leitungen 
mal anschauen usw.

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.