suche was zum CS8406 vergleichbares aber mit parallelem Eingang

da habe ich wohl gestern vergessen dazu zu schreiben das der CS8406 ein digitaler Audio-Transmitter für SPDIF ist. Das heist das er die nackten Digital-Audio-Daten ins SPDIF-Format umsetzt (mit Framing u.s.w.) und das Bi-Phase-Encoding macht.

Hoffe ich habe nicht zu viel Verwirrung gestifted. Erik

"Erik Groß" schrieb:

Hallo Erik,

Ähem, 48kHz * 16bit * 2 Kanäle = 1,5Mbit/s, oder? Ist natürlich immer noch viel, wenn zwischendurch noch andere Routinen laufen...

Das hat aber auch seinen Charme.

Ich beschäftige mich auch gerade mit der S/PDIF-Übertragung und hab das CS8406 Datenblatt durchgelesen. Leider kenne ich momentan auch noch keine Alternative mit Paralleleingang. Ich kenn noch nicht mal einen anderen S/PDIF-Audio-Transmitter außer CS8405/06. Was gibt's denn da noch?

Wenn alle Massepfade reissen, sprich, es gibt keinen mit Paralleleingang, könntest Du einen Parallel/seriell-Wandler wie den 74HC674 vorschalten. Den kannst Du mit 16bit parallel reinhauen und dann seriell in den CS8406 takten. Dem ist dann bei Deiner Taktgeschwindigkeit langweilig, der kann so 20MHz, wenn ich mich recht entsinne.

Um was für eine Anwendung geht's denn da?

Für mein Projekt suche ich einen MP3-Dekoder mit S/PDIF-Ausgang. Alle, die ich bis jetzt gefunden habe, sind mit I2S- oder Analogausgang. Vielleicht kannst Du mir da weiterhelfen. Da wir an ähnlichen Anwendungen arbeiten, könnten wir gegebenenfalls Wissen und Erfahrungen austauschen.

Gruß, Patrick

"Erik Groß" schrieb:

Hallo Erik,

Ähem, 48kHz * 16bit * 2 Kanäle = 1,5Mbit/s, oder? Ist natürlich immer noch viel, wenn zwischendurch noch andere Routinen laufen...

Das hat aber auch seinen Charme.

Ich beschäftige mich auch gerade mit der S/PDIF-Übertragung und hab das CS8406 Datenblatt durchgelesen. Leider kenne ich momentan auch noch keine Alternative mit Paralleleingang. Ich kenn noch nicht mal einen anderen S/PDIF-Audio-Transmitter außer CS8405/06. Was gibt's denn da noch?

Wenn alle Massepfade reissen, sprich, es gibt keinen mit Paralleleingang, könntest Du einen Parallel/seriell-Wandler wie den 74HC674 vorschalten. Den kannst Du mit 16bit parallel reinhauen und dann seriell in den CS8406 takten. Dem ist dann bei Deiner Taktgeschwindigkeit langweilig, der kann so 20MHz, wenn ich mich recht entsinne.

Um was für eine Anwendung geht's denn da?

Für mein Projekt suche ich einen MP3-Dekoder mit S/PDIF-Ausgang. Alle, die ich bis jetzt gefunden habe, sind mit I2S- oder Analogausgang. Vielleicht kannst Du mir da weiterhelfen. Da wir an ähnlichen Anwendungen arbeiten, könnten wir gegebenenfalls Wissen und Erfahrungen austauschen.

Gruß, Patrick

z.B. Micronas MAS35x9 kann auch S/PDIF ausgeben... Gruß Ing.olf

--
Ingolf Pohl

Hallo Patrick Kaupp,

Ich dachte der Tackt für dieses serielle Interface is Fs * 64, aber Du hast recht es geht wohl auch asyncron mit etwas geringerer Bitrate. Ich hatte mir das Datenblatt noch nicht so genau angesehen.

Eben, ich muss einige Daten auswerten und diese dann zum PC schicken. Messaufgabe zur Überwachung von Datenleitungen. Dafür möchte ich das Audio-Interface mißbrauchen. Schließlich beherrscht es hohe Bitraten und ist Platformunabhängig standartisiert. Die Auswertungssoftware möchte ich in Java programmieren und das kann dann auf allen wichtigen Platformen (Linux,Windoofs und Mac) ohne Anpassungen laufen. Nen digitalen Audio-Eingang gibts für 30 Euronen bei Mediamarkt und co. zum Anschluß an USB.

Ist für mein gegebenes Projekt definitv das falsche Werkzeug.

Mein Kenntnisstand ist da nicht signifikannt größer. Den CS8405 hab ich mal vor einiger Zeit bei der Recherche für ein privates Projeckt (sie unten) gefunden und mich nun wieder daran erinnert. Was vergleichbares von anderen Herstellern kenn ich aber auch nicht. Paralleleingang wirds wohl nicht geben das 3 bis 6 Mbit (bis 96kHz) noch problemlos seriell machbar sind und wenn der Transmitter nicht im 28 Pin- sondern im 88 Pin-gehäuse kommt (und damit auch mehr Leiterplattenfläche belegt) wird er wohl zu teuer für die angesagten "Ich-bin-doch-zu-blöd-Produkte" werden.

Den

Dazu hat mir Google leider kein Datenblatt sondern nur Restposten-Händler gebracht.

Da mein derzeitiges Projeckt eigentlich gar nichts mit Audio zu tun hat, kann ich Dir leider nicht wirklich weiterhelfen. In einem anderen Projeckt (privater Natur) mach ich zwar mit S/P-DIF aber das komplett in nem FPGA (fürs Bi-Phase-En/De-coding) und in Software (fürs Framing und Audioprocessing). Aber auch hierfür verwende ich keinen Audio-DSP sondern einen richtigen PC wo der FPGA am PCI-Bus hängt und meine SW (ohne störendes Betriebssystem) die volle CPU-Power genießen kann. Schließlich kann ein guter Assemblerprogrammierer so wie ich aus SSE2 (mit fetten GHz) einiges mehr raus holen als aus nem Audio-DSP bei dem das Entwicklungsboard mit Entwicklungsumgebung mehr kostet als ein kleiner Geiz-ist-geil-PC sammt Monitor für die Visualisierung.

Grüße Erik

Von Yamaha gabs auch was aber mir will gerade die Nummer nicht einfallen.

Olaf

Ingolf Pohl schrieb:

Danke für die Info, Ingolf. Werde ich mir am Wochenende mal reinziehen.

Gruß, Patrick

"Erik Groß" schrieb: Hi Erik,

[snip]

Aha, auch eine Möglichkeit. Dabei mußt Du dann aber nicht wie bei einer Audio-Anwendung unbedingt kontinuierlich senden, oder?

Ok.

[snip]

Zumindest Sony und Philips sollten doch da noch was haben; schließlich haben die diese Schnittstelle damals aus der Taufe gehoben. Allerdings kommen die Audio-Daten immer seriell von der CD, so daß ich glaube, daß Du keinen mit einer parallelen Schnittstelle finden wirst.

[snip]

Kann sein, daß das Teil abgekündigt ist, hatte ich damals in meiner Diplomarbeit verwendet. Bei Philips find ich's auch nicht mehr. Aber schau mal hier

Da gibt's einige Schieberegister parallel in/serial out, leider nur 8 bit, aber Du kannst ja 2 kaskadieren. Der 74HC674 war damals auch recht teuer im DIL24. Außerdem besteht noch die Möglichkeit, sich sowas in einem PLD zusammen zu nageln.

Schade.

[snip]

An einen FPGA, der MP3-Dekodierung und S/PDIF-Codierung macht, hab ich auch schon gedacht. Aber erst mal scannen, was es schon fertig gibt. Werde mal dem Tipp von Ingolf nachgehen. Gegebenenfalls mach ich hier im Forum einen neuen Thread auf, bevor Deiner OT wird ;)

Gruß, Patrick

Moin!

Und ein paar Schieberegister zur Wandlung sind nicht teuer, nehmen aber Platz weg und wollen auch angesteuert werden. Ein CPLD kann das Platz- und Routingproblem recht bequem lösen, wenn man mag auch gleich das S/P-DIF generieren.

Zumindest S/P-DIF ist ziemlich trivial, sobald man das komische Format mit seinen Subbits, Bits, Worten, Frames, Blöcken und Präambeln erstmal durchblickt hat. "Früher" habe ich sowas einst aus Schiebe- registern, 1 oder 2 FFs und XOR von Hand zusammengestrickt, also parallel rein -> S/P-DIF raus. Ablaufsteuerung hatte ich mit nem Eprom aufgebaut, dessen Adressen zyklisch hochgezählt wurden und dessen Datenbits dann SR-Clock, Präambel etc. getriggert haben. Heute würde ichs in ein CPLD packen. 16 Makrozellen für das Datenbit-SR + 1 für Parity + 6 für den Clockzähler + 8 für den Framezähler. Mit etwas Geschick evtl in 36 Makrozellen machbar, in 72 Makrozellen sicher problemlos, dann kann man auch gleich noch ein Sample buffern. Und für PLCC gibts lochrasterkompatible Fassungen.

Gruß, Michael.

Hallo Patrick Kaupp,

doch, doch. Der S/P-DIF-Strom darf nicht abreißen sonst kommt die Soundkarte durcheinander.

wirst.

naja, nach der Fehler-Erkennung/Korrektur sollten sie als 32bittige Samples vorliegen. Ich denke das da eher der Kostenfactor eine Rolle spielt. Jedes Pin kostet Geld.

Ich hab hier noch ne gute Hand voll CPLD's von Xilinx rumliegen, damit könnte ich das ganz sicher, aber wenn ich das schon in VHDL mache dann solls auch gleich noch nen USB-Interface bekommen. Schließlich ist für mich das S/P-DIF nur Mittel zum Zweck. Ich will die Mess-Daten als Audio-Stream in den PC bekommen, das 'Wie' ist mir fast egal.

auch

Daher nur der Tip :

da gibts alles was Du sucht, sogar den MP3-Decoder

Grüße Erik

Hi!

Hast Dir mal den USB-Chip FT245BM angeschaut? Der hat hardwareseitig einen Port mit 8bit + Clock, nen Fifo drin und installiert sich gegenüber Windows als serieller Port bis 300kByte/s (kann aber auch via dll direkt angesprochen werden und macht dann bis 1MByte/s). Treiber gibts direkt bei ftdi für Win/Linux/Mac.

Gruß, Michael.

Hallo Michael Eggert,

leider ist die RS232-Schnittstelle nicht als standardisierte USB-Device-Class verfügbar so das jeder Hersteller sein eigenes Süppchen kochen muss. (Klar reduziert sich das auf wenige Chip-Hersteller, die auch den passenden Treiber dem Manufactor mitliefern, aber es bleibt eine propritäre Lösung die man nicht ohne weiteres portieren kann.) Außerdem sind mir 8 Bit zu wenig. Das Audio-Interface (zumindest die Basisfunktionen) ist für USB standartisiert (Audio-Class : ), funktioniert also auch ohne herstellerspeziefische Treiber und wird z.B. von der Java-VM auf allen wichtigen System native unterstützt (keine DLL oder ähnlicher Quatsch). Deshalb hab ich mich für das Audio-Interface als Datenschnittstelle und Java als portables Programmiersystem entschieden.

Grüße Erik

Hallo Michael,

Ganz so leicht sollte man sich das dann doch nicht machen. Heutzutage werden in den Sub-Chanels verschiedene Infos mittransportiert (von der Position im Titel über den Titel-Name bis hin zum Songtext ist fast alles möglich, viele neuere CD's bieten diese Infos auch). Deshalb habe ich in meinem privatem Projekt das Framing auch in Software realisiert und schicke dem FPGA die fertigen 64Bit für jedes L/R-Pärchen. Die Preambles schicke ich kodiert mit, soll heisen für die drei möglichen Preambles schicke ich drei verschiedene vordefinierte Bitmuster welche dann nicht normal Bi-Phase-Codiert werden sondern das gewünsche Preamble in einem Speicher addressieren. Ist natürlich etwas aufwendiger aber es lohnt sich wenn man den "Mehrwert" auch möchte.

Grüße Erik

Hi!

Für "fast egal" stellst aber ganz schön viele Ansprüche :-)

Gruß, Michael.

Hi!

Kommt drauf an, was man will. Ich brauchte einen hochauflösenden D/A-Wandler für eine Regelung, der nicht unbedingt hochlinear, dafür aber absolut monoton sein musste (sonst geht die Regelung daneben). Delta-Sigma AudioDACs haben sich da praktisch angeboten, und das S/P-DIF Interface auf billiger Plastikfaser hat gleich für die galvanische Trennung im System gesorgt. Mit Subchanneldaten hätte ich da reichlich wenig anfangen können. Und auch im Ursprungsposting fragst Du nur nach 2x16Bit.

Sofern man das auf 32Bit reduziert, sollte auch das in 72 Makrozellen machbar sein. Um was für ein Projekt handelt es sich denn, daß es einen 64bit-Datenbus erfordert?

Gruß, Michael.

Hallo!

Michael Eggert schrieb:

r

la=DF mich raten, eine Positionierung?

Mu=DF der Wandler schnell sein?

--

Mit freundlichen Gruessen       Dipl.-Ing.(FH) Thomas Budich
[   E-Mail Antworten hierauf werden automatisch gel=F6scht   ]

also diese beiden "Ansprüche" laufen ja wohl auf das selbe hinaus : Portabel.

So stelle ich mir die endgültige Lösung vor :

Eine kleine Schachtel mit USB-Anschluss (und natürlich die Mess-Anschlüsse) mit nem FPGA und 2 AD's drin. Der FPGA meldet sich als USB-Hub mit zwei weiteren Devices, ein Standart-Sound-Device und ein Standart-Mass-Storage-Device, am System an. Beide Devices werden vom System automatisch eingebunden. Das Sound-Device wird ans Sound-System angekoppelt und das Mass-Storage-Device (wie ein USB-Stick) wird ins Dateisystem integriert. Dort befindet sich eine kleine JAR-Datei mit dem Java-Programm welches einfach gestarted wird, sich sein zugehöriges Sound-Device sucht und schon läuft die Sache. Das starten kann man bestimmt auch unter allen wichtigen Betriebssystemen automatisieren. Also echtes "Plug-and-Play".

Ich weis das dieser Traum nicht bis morgen fertig ist, deshalb möchte ich klein anfangen. Aber prinzipiell bin ich als Entwickler wie auch als User an einer ordentlichen Lösung interessiert.

ich brauche halt 2 * 16Bit

Erik

Hallo,

Damit wollte ich nicht sagen das Deine Lösung nicht funktioniert oder das ein PLD zu schmächtig dafür ist, ich wollte eher ausdrücken das man dem S/P-DIF Protokoll nicht gerecht wird wenn es derart reduziert wird. Klar gibt es nicht viele Situationen wo der volle Umfang wirklich nötig ist, aber gerade im Audio-Bereich kann das schon nützlich sein wenn ein paar zusätzliche Infos mit übermittelt werden. Mann sollte das eben von Fall zu Fall entscheiden was man in ein Produkt integriert und auf was man auch schmerzfrei Verzichten kann.

ACK

In meinem aktuellem Project sehe ich auch keine Verwendung für diese Zusatzinfos, schon weil ich diese wiederrum nicht Platformunabhängig auswerten kann. Auch in der USB-Audio-Device-Class sind die wohl nicht ohne weiteres realisierbar.

Äh ?? mit 64Bit meinte ich "L/R-Pärchen" (siehe oben), also 2*32 Bit für "Links" und "Rechts" zusammen. So das ich mit einer Übertragung pro Sample-Takt auskomme, was auch den PCI-Bus spürbar entlastet. Da ich in diesem Projekt sogar 3 Audio-Ausgänge hab schicke ich gleich 256Bit auf einmal los, so kann der PCI-Bus gleich 8 DWORD am Stück bursten. Und der FPGA nimmt das Packet dann auseinander, analysiert den Header und handelt entsprechend.

Grüße Erik

Hi!

Knapp daneben, Laserfrequenzregelung.

Die damals aktuellen 48kHz waren eigentlich genau richtig...

Gruß, Michael.