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?
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 ;)
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.
> 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...
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.
> 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.
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
> 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? ;)
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 :-(
Angehängte Dateien:
-
DSP_Board_Top.jpg
140 KB -
DSP_Board_Bottom.jpg
130 KB -
DSP_Board.png
50 KB
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?
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.
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
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
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.
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
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.