Liebe Leute,
für ein Selbstbauprojekt suche ich SPDIF-Empfänger und SPDIF-Sender, die möglichst keine Auswertung von Non-Audiodaten auf dem Chip vornehmen, sondern lediglich den Audio-Datenstrom und den Non-Audio-Datenstrom voneinander trennen, bzw. zum SPDIF-Signal zusammenführen.
Vergleichbares gab es mal von Motorola mit dem DSP56401, aber der ist lange abgekündigt. Was nimmt man denn heute so?
Viele Grüße, Holger
Ich kenne von einem Projekt den AK4117, wo der als Clock-Rückgewinnungsbaustein eingesetzt wird, mit anschließendem FPGA zum dekodieren und codieren. Die Spannungsversorgung für den AK4117 ist ein wenig kritisch, muß man per Drossel usw. aufwändig entkoppeln, sonst läuft es nicht stabil bis 192 kHz, aber ansonsten macht der Baustein keine Probleme. Er kann auch selbst dekodieren, wenn du keinen FPGA dahinter setzen willst (bei nur einem Kanal könnte aber auch ein kleiner CPLD reichen) und gibt glaube ich auch komplementäre Bausteine zum generieren des AES/EBU-Signals.
Am 03.06.2010 13:47, schrieb Holger:
Hallo Holger,
nur um das mal (vielleicht auch nur begrifflich) klarzustellen: Du kannst über S/P-DIF _entweder_ Audio-Daten _oder_ non-Audio-Daten (z.B. AC3, DTS) übertragen.
Ich vermute jetzt einfach mal, dass Du mit Non-Audiodaten die Status-Bits und User-Daten meinst.
Außer AKM (von Frank schon genannt) sind die üblichen Verdächtigen da Cirrus Logic (z.B. CS8406, CS8416) und Texas Instruments (z.B. DIX4192), evtl. auch Analog Devices (weiß nicht genau, ob die was brauchbares haben).
Die Bausteine von Cirrus Logic kannst Du auch ohne Microcontroller im Hardware-Modus betreiben, außerdem sind sie im handlötungsfreundlichen SOIC-Gehäuse erhältlich und sind mit _einer_ Betriebsspannung (3,3V) zufrieden.
Viele Grüße Markus
Markus Faust schrieb:
Validity, User,, CRC, Parity- Diese Bits. Der DSP56481 separiert sie als Non-Audio-Daten.
Hab ich schon gefunden. Sie ganz nett aus. Komplett alles auf einem Chip, Wandler und Transceiver.
Der DSP56481 ist schon ganz cool. Du kannst sämtliche Schweinereien im Userdatenfeld sehen, Schreibschutzbit inklusive. Das ist mit den anderen Chips irgendwie nicht wirklich drin. Dafür sind sie schaltungstechnisch weiter. Ich habe zum Beispiel Pre- und Deemphasis extern implementiert, leider nicht ganz vorschriftsmäßig, aber immerhin. Weil ich aber alles lesen kann, kann ich auch alles schreiben, und bei den neueren Chips habe ich nicht so die Kontrolle, hätte sie aber gerne.
Holger
Am 03.06.2010 23:56, schrieb Holger:
Bei den meisten aktuellen Bauelementen wird der Begriff "Non-Audio-Daten" im Zusammenhang mit Bit 1 im Byte 0 der Statusbits gebraucht und bezieht sich auf die Daten im Hauptdatenfeld.
Parity und CRC werden von den meisten aktuellen Bauelementen automatisch erzeugt/ausgewertet, ansonsten hast Du ziemlich freie Hand. Viele Hersteller gehen mittlerweile wohl davon aus, dass der Anwender diese per I2C oder SPI reinklimpern/auslesen möchte.
Wenn Du wirklich mit Parity und/oder CRC spielen willst (um Fehler zu simulieren?) würde ich vielleicht eher eine Implementation auf einem kleinen FPGA vorschlagen. ;-)
Markus
Have something to add? Share your thoughts — no account required.
Ask the community — no account required