Ich habe mir zusammen mit einem weiteren Entwickler folgendes Hobbyprojekt vorgenommen: Ein Universalaudiogerät. 8 Analogeingänge 8 Analogausgänge USB-Audioschnittstelle über Audio-Class, 8 kanalig Audio over Ethernet, 32 kanalig Master Samplingfrequenz 44.1 kHz oder 48 kHz Betrieb als Clockslave wahlweise am Ethernet oder an Wordclock Signalprocessing in einem Sigma-DSP Zwischen den AD- und DA-Wandlern und dem Sigma-DSP wird das TDM Format verwendet. Jetzt stellt sich die Frage, wie das Gerät strukturiert wird. An zentraler Stelle soll ein FPGA zum Einsatz kommen. Dort laufen alle TDM Datenströme auf und werden von der gewählten Quelle an das gewählte Ziel geroutet. Es gibt maximal 16 aktive Mono-Routen. Also wäre eine mögliche Einstellung z.B. alle 8 Analogeingänge auf USB und 8 Signale von Ethernet auf Analog. Jetzt ist die Frage, ob für USB und Netzwerk ein extra Prozessor verwendet werden soll oder ob diese Funktionen je als Softcore in den FPGA kommen. Es sollten keine komplizierten Rechnungen im FPGA ausgeführt werden, also nur Routing und Paketbildung. Alle mathematische Signalverarbeitung passiert im Sigma-DSP. Welchen FPGA würdet ihr empfehlen? Womit lässt sich USB Highspeed am besten implementieren? Oder sollte ich den FPGA oder in dem Fall viellecht sogar nur ein CPLD wirklich nur als Router nehmen und alle Schnittstellen auf externe Prozessoren ausgliedern? Wenns fertig ist, wird das Projekt voraussichtlich Open Source. Als Arbeitszeit sind 1,5 Hobbymannjahre vorgesehen. Ich habe keine Entwicklungsumgebung mit Subscription, sondern nur die Web-Edition von Xilinx und Altera zur Verfügung. Ich freue mich über jeden nützlichen Hinweis, Links auf ähnliche oder dafür brauchbare Projekte oder Codeschnippsel, besonders, was USB und Ethernet angeht. Grüße, Peter
Peter Diener schrieb: > Ich freue mich über jeden nützlichen Hinweis, Links auf ähnliche oder > dafür brauchbare Projekte oder Codeschnippsel, besonders, was USB und > Ethernet angeht. Da ist http://opencores.org/projects DIE Anlaufstelle, insbesondere wenn dar Projekt unter GPL/LGPL gestellt werden soll. Viele Projekte sind aber Verilog, wenn man selbst VHDL vorzieht wäre zu klären ob die freien Xilinx/Altera Tools mixed Language unterstützen. Das mit USB im FPGA würde ich mir genau überlegen, die Audio Class ist ziemlich kompliziert. Für Highspeed wäre eventuell der Cypress FX2 die bessere Wahl der USB Anbindung.
Danke für die Info, opencores kenn ich schon, es sind auch viele brauchbare Sachen dabei. Ich persönlich bevorzuge eigentlich VHDL. Das mit den Einschränkungen der kostenlosen Tools hab ich auch noch nicht genau recherchiert. Interessant ist vor allem auch, ob es eine Begrenzung der Komplexität gibt oder manche FPGAs von vornherein ausgeschlossen sind. Die FX2 und FX3 von Cypress kenn ich auch schon, das wäre dann eine der Möglichkeiten bei externem USB-Prozessor. Und wenn dann gleich auf USB3.0 Das ist halt die Frage, wie kompliziert die Audio-Class ist. Bisher hab ich das nur auf einem PIC32 mit der mitgelieferten Lib ausprobiert. Werd ich wohl mal auf einem meiner FPGA Demoboards probieren müssen... Genaugenommen hab ich auch nichts gegen eine reine CPU-Lösung ohne FPGA, aber die müsste jede Menge TDM Schnittstellen haben, also gleich was in der Größenordnung TMS320C6720 o.Ä. Und der hat dann weder einen Ethernet MAC, noch USB, würde also nur das Routing machen. Ist irgendwie auch nicht das wahre.
USB3.0 würde ich sein lassen. Die Anwendung braucht es nicht und es fügt statt dessen einiges an Komplexität hinzu. Was auch zu klären wäre: sind BGA Bausteine (FPGA/CPU) akzeptabel? Die freien Tools der FPGA Hersteller haben natürlich Grenzen von dem was sie unterstüzten. Dürfte sich aber an den Typen/Grösse bzw Familien aufhängen. Bei Lattice werden z.B. die ECP2M und ECP3 Familien nicht unterstützt, aber alle andere.
Mit einem USB Softcore machst du dir keine Freude. Schon gar nicht HighSpeed. Der FT232H oder FX2/FX3 ist da wesentlich einfacher handhabbar. Mit dem FX3 spiele ich gerade rum, ist kaum mehr zu tun als am FX2, im Gegenteil, durch den ARM Core ist das alles etwas angenehmer.
Willst Du auch den Analogteil bauen? Was soll das universale Gerät können? Soll auch externes Equiment angeschlossen werden? Warum die Beschränkung auf 48kHz?
BGA würde ich nur machen, wenn es unbedingt sein muss. Ja, der FX3 wäre schon nicht schlecht. Kann der denn TDM Schnittstellen? Auf die Schnelle hab ich nichts dazu gefunden. Die Cypress PSoC wären vielleicht auch eine Alternative für den USB-Teil. Vielleicht kann man durch den integrierten PLD-Teil eine TDM-Schnittstelle basteln. Alternativ könnte der Routing-FPGA auch eine andere Schnittstelle (z.B. parallel slave port) zum USB-Controller haben. Der USB-Controller könnte den FPGA wie Speicher ansprechen um die Audiodaten zu übertragen. Die Wandler und der Sigma-DSP bleiben bei TDM als Schnittstelle. In ersten Versuchen wird die Hardware mit Sicherheit auch nicht in voller Komplexität aufgebaut werden. Ich habe daran gedacht, erst mal ein normales USB-Analog-Interface zu bauen. Dann kommt der Routing FPGA. Damit kann man zwar noch nicht viel anfangen, wenn es nur Analog- und USB-Schnittstellen gibt, aber Loopbacktests und Signalduplizierung soll möglich sein. Dann kommt der schwierige Teil AudioOverEthernet. Ich werde vermutlich ein eigenes Protokoll basteln. Wie bei Ethersound soll es einen Clockmaster im System geben, der Sync-Pakete broadcastet. Alle anderen Netzwerkteilnehmer erzeuegen daraus per geeigneter PLL ihren Takt für die AD- und DA-Wandler und daraus geteilt den Wordclock. Die Datenübertragung soll direkt über die Payload im Ethernetframe passieren, ohne weiteren Protokollstack. Anders wird vermutlich die Latenz recht schwierig zu beherrschen sein. Routingfähig muss es nicht sein, wenn es über Switches funktioniert, reicht das. Bei der Ethernetsache bin ich mir auch noch nicht sicher, ob im FPGA oder in einem separaten Prozessor. Im Moment tendiere ich zu einem PIC32, der über den ParallelMasterPort die Daten zum FPGA sendet bzw. dort abholt. Dann stellt sich die Frage, ob man für Ethernet und USB den selben Controller verwendet, oder zwei separate. Im Moment bin ich für die Lösung mit zwei separaten. Vielleicht baue ich als Zwischenschritt auch ein Gerät, das nur von USB nach Ethernet Audio überträgt. Daran wird dann die Taktrückgewinnung aus den Sync-Paketen erprobt.
>Willst Du auch den Analogteil bauen? Ja klar. Analogseitig soll es 8 symmetrische Ein- und Ausgänge auf XLR geben. Später kommt dann vielleicht ein digital stellbarer Vorverstärker und Phantomspeisung. Ich gehe davon aus, dass mein Kollege die Analogsache weitgehend übernehmen wird. >Was soll das universale Gerät können? Ersatz für das klassische Multicore. Intelligente Stagebox, die z.B. direkt auf der Bühne einen Monitormix rechnen kann. Rechnergesteuertes Mischpult, über LAN steuerbar, I/Os verteilt über mehrere Netzwerkknoten. Einfache Mitschnittmöglichkeit über Rechner am USB. >Soll auch externes Equiment angeschlossen werden? Da spricht nichts dagegen. Also der Netzwerkteil muss (noch) nicht zu anderen Geräten kompatibel sein. Aber die USB-Schnittstelle soll ein standard 8 Kanal USB Audiogerät sein. Und die Analogschnittstellen sind natürlich kompatibel zu dem gängigen Studio- und Liveequipment. >Warum die Beschränkung auf 48kHz? Ich hab eben einfach mal eine Grenze gezogen, die ist aber nicht fix. Wenn sich rausstellt, dass mehr geht, gibts mehr. Die Wandler, die mein Kollege ausgesucht hat und der DSP kann jedenfalls mehr. Genauso könnte man sagen, warum nicht 128 Kanäle auf den Ethernet. Was ich oben geschrieben habe, sind Mindestwerte, die ich gerne erreichen möchte. Alles darüber ist erstmal nur nice to have.
Peter Diener schrieb: > BGA würde ich nur machen, wenn es unbedingt sein muss. > das begrenzt die FPGA Auswahl erheblich. Aber alle FPGAs im TSOP dürften von den freien Versionen der Tools unterstüzt werden. Auch der FX3 fällt flach, gibts nur in BGA. Ist dafür schnuckelig klein :-) > Ja, der FX3 wäre schon nicht schlecht. Kann der denn TDM Schnittstellen? > Auf die Schnelle hab ich nichts dazu gefunden. Kann er sicher nicht, man bereitet die Daten extern parallel auf und überträgt sie in einen Fifo im FX3. > > Die Cypress PSoC wären vielleicht auch eine Alternative für den > USB-Teil. Vielleicht kann man durch den integrierten PLD-Teil eine > TDM-Schnittstelle basteln. Die PSoC haben leider nur ein USB Fullspeed Interface, und das reicht nicht für 16 Kanäle a 16bit und 48 kHz. (von 192 kHz und 24/32 Bit braucht man gar nicht erst träumen) Zu deinen Ideen bezüglich Ethernet kann ich wenig sagen, nur soviel dass eine Implementation im FPGA nicht so viel Aufwand ist (ohne TCP, d.h. UDP/RTP only), und auch der Jitter der Syncpackete IMO leichter in den Griff zu bekommen ist. Braucht aber etwas Resourcen, womit die Begrenzung auf TSOP Gehäuse schon im Wege stehen kann. Aber trotzdem, wenn schon BGA Bauteile warum sich dann nicht eine Stufe höher und die DaVinci (oder OMAP) Prozessoren von TI anschauen?
Ein paar kurze Anmerkungen: - Ein FT2232H z.B. erschlägt die Anbindung per USB-FIFO und gleich die JTAG-Schnittstelle zur Programmierung von FPGA. - Alternativ dazu könnte man auch den ADI BF527 mit USB und Ethernet evaluieren. Mit Realtime-uClinux eine industriereife Sache, sofern 100 MBit Ethernet reichen. - Das lästige Problem mit den USB IDs wäre damit (mit beiden Lösungen) auch vom Tisch, von FTDI bekommt man locker 8 PIDs, unter uClinux kann man die Gadget-Treiber nutzen. Beim FX2/3 eine andere Geschichte, da sind fürs Endprodukt mit VID/PID auf jeden Fall 2k$ fällig. Das FPGA als "Front end" zu benutzen ist noch recht tough, wenn man bei Null anfängt, da will so einiges für die Datenübertragung entwickelt werden (FIFOs, DMA, Arbiter, geschweige denn, das alles mit einer geeigneten SoftCPU zu versehen). Eher akademisch wertvoll als wirtschaftlich... Eher würde ich das FPGA als Parallelizer von SPORT (TDM) in Richtung Highspeed-Lane (PPI, etc.) verwenden. Grüsse, - Strubi
Ein paar Anmerkungen zu den Anmerkungen Strubi schrieb: > - Ein FT2232H z.B. erschlägt die Anbindung per USB-FIFO und gleich die > JTAG-Schnittstelle zur Programmierung von FPGA. Der FT2232H kann meines Wissens kein USB Audio, fällt also aus. Ist aber trotzdem sinnvoll ihn als JTAG Adapter für FPGA und z.B. ARM Debugger mit einzudesignen. Ich habe schon FPGA Evaluations Boards mit FT2232H für den Programmer und einen FX2 für die eigentliche Anwendung gesehen. > - Alternativ dazu könnte man auch den ADI BF527 mit USB und Ethernet > evaluieren. Mit Realtime-uClinux eine industriereife Sache, sofern 100 > MBit Ethernet reichen. Der Blackfin ist tatsächlich einer nähreren Betrachtung Wert, ist ganz sicher einfacher bezgl. HW zu als der TI DaVinci und deckt mehr gewünschte Funktionen ab als ein FX2/3 http://www.analog.com/en/processors-dsp/blackfin/adsp-bf527/processors/product.html > - Das lästige Problem mit den USB IDs wäre damit (mit beiden Lösungen) > auch vom Tisch, von FTDI bekommt man locker 8 PIDs, unter uClinux kann > man die Gadget-Treiber nutzen. Beim FX2/3 eine andere Geschichte, da > sind fürs Endprodukt mit VID/PID auf jeden Fall 2k$ fällig. Für ein Hobby Projekt würde mir die USB ID keine schlaflosen Nächte bereiten, schon gar nicht für USB Audio das mit Standard Treibern laufen sollte. > Das FPGA als "Front end" zu benutzen ist noch recht tough, wenn man bei > Null anfängt, da will so einiges für die Datenübertragung entwickelt > werden (FIFOs, DMA, Arbiter, geschweige denn, das alles mit einer > geeigneten SoftCPU zu versehen). Eher akademisch wertvoll als > wirtschaftlich... Hobby Projekte sind sehr selten wirtschaftlich. > Eher würde ich das FPGA als Parallelizer von SPORT (TDM) in Richtung > Highspeed-Lane (PPI, etc.) verwenden. Von viel mehr war bisher auch nicht die Rede, schon gar nicht von einer SoftCPU.
>Der FT2232H kann meines Wissens kein USB Audio, fällt also aus.
Was ist den USB-Audio ?
Er meint wohl isochrone Übertragung..die sollte aber beim FT2232H theoretisch gehen. Ist nur nicht von den üblichen Libraries unterstützt. Zur Wirtschaftlichkeit: Klar muss ein Hobbyprojekt nicht 'wirtschaftlich' sein. Ich bin halt eher einer derjenigen, die kleine Schritte machen und die Sache gern simpel halten (u.a. auch zur Frustminimierung :-) ) Sofern man ein Team von Spezialisten/Enthusiasten findet, von denen jeder das beiträgt, in dem er seine Expertise besitzt, kriegt man so komplexe Dinger schon gebacken. Aber als (ev. unbezahlter) Einzelkämpfer auf vielen Hochzeiten zu tanzen ist echt nicht so ohne... Als Referenzprojekt, das in ähnliche Dimensionen vorstösst, könnte man ev. das Milkymist (http://milkymist.org/) beiziehen.
Um den FT2232 als USB Audio Device zu benutzen, müsste man isochrone Endpoints haben und die USB Device Class anpassen können. Beides geht meines Wissens nicht. Sowas geht nur mit frei programmierbaren USB Controllern wie FX2. Der FX3 hat I2S Hardware, falls das hilft.
Strubi schrieb: > Er meint wohl isochrone Übertragung..die sollte aber beim FT2232H > theoretisch gehen. Ist nur nicht von den üblichen Libraries unterstützt. isochrone Übertragung ist Bedingung für USB-Audio, aber nicht die einzige. Das Device muss darüberhinaus noch einiges an Interfacespecific Commands ausführen. Und mit Libraries auf der PC Seite kann man nichts richten, das muss mit dem generischen Windowstreiber funktionieren, und auch bei Linux ist das sicher hilfreich (sonst noch ne Baustelle). > Ich bin halt eher einer derjenigen, die kleine > Schritte machen und die Sache gern simpel halten (u.a. auch zur > Frustminimierung :-) ) Das ist sicher ein Rat den viele beherzigen sollten.
habt ihr noch nie eien USB Soundkarte gesehn? Es gibt eine USB Audio Class. Da brauchts keinen Treiber, allerdings muss die Firmware sich eben so verhalten, wie es die USB Audio Class verlangt.
> Was ist den USB-Audio ? http://www.usb.org/developers/devclass_docs Mit der USB Audio Class wird ein USB Gerät von aktuellen Betriebssystemen direkt als Audioausgang oder Audioeingang verwendet, ohne, dass man spezielle Treiber braucht. Ursprünglich hab ich mir mal den TUSB3200a von TI als USB-I²S Interface angesehen. Der wäre auch ok, wenn nicht die Begrenzung wäre, dass er nicht alle 8 Kanäle in die gleiche Richtung kann. Er kann z.B. 6 Out und 2 In. Ich hab mir das Audioframework für die TI C5000 angesehen, das kann im Moment leider nur Stereo. Alles darüber muss man komplett selber machen, dann kann ich auch was anderes nehmen. Den Blackfin werd ich mir mal genauer ansehen, besonders das Codec-Interface. Die Sache mit dem FT2232H sieht recht umständlich aus, bzw. geht wohl für isochronous transfer gar nicht. Als nächstes probier ich mal mit dem PIC32 (für den hab ich ein Demoboard hier) einen Loopbacktest mit USB Audio. Vielleicht lässt sich das entsprechend auf 8 Kanäle erweitern. Der hat halt kein Codec-Interface, aber das von parallel auf TDM zu wandlen sollte im FPGA das kleinste Problem sein. Alternativ einen dsPIC33, die gibts mit USB und Codec-Interface. Am schönsten wäre natürlich für den Anfang eine fertige Lösung, wie der TUSB3200a, nur eben für 8 Kanäle in eine Richtung.
Christian R. schrieb: > Um den FT2232 als USB Audio Device zu benutzen, müsste man isochrone > Endpoints haben und die USB Device Class anpassen können. Beides geht > meines Wissens nicht. Sowas geht nur mit frei programmierbaren USB > Controllern wie FX2. Der FX3 hat I2S Hardware, falls das hilft. Nur die USB Device Class im Device- bzw Interfacedescriptor anzupassen reicht nicht, man muss auch die ganzen Audiodescriptoren anlegen. Ich habe das FX3 Datenblatt überfolgen, das I2S Interface geht nur für Ausgabe. Man muss schon das parallel Interface nutzen.
>Studioequipment Da läuft das meiste auf 96kHz und einiges bereits auf 192kHz. SW produziert schon auf 384kHz - jeweils Stereo pro line. Peter Diener schrieb: > einen Loopbacktest mit USB Audio Da würden mich mal die Latenzen interessieren
Ich weiß, dass wirklich teure Studiogeräte wesentlich höhere Samplingraten können. Das liegt auch daran, dass man die aufwändige Analogfilterung zur Bandbegrenzung dann gegen nicht so steile Filter ersetzen kann, die dann weniger rauschen. Im Rechner kann man die Bandbegrenzung vor dem downsampling dann in 64 Bit praktisch rauschfrei rechnen. Nur ganz wenige Produktionen laufen bis zum Master in der hohen Samplingrate. Und der Nutzen wird auch immer wieder angezweifelt. Mir reichen die 44.1 kHz jedenfalls vorerst, später kommen vielleicht mal bis zu 96 kHz, dann ist beim Sigma-DSP die Grenze erreicht. Die Experimente mit dem PIC32 laufen grad auch nicht so gut, ich hab jetzt zwar ein Beispiel von einem anderen Demoboard auf meins portiert, aber momentan mag der Onboard-Debugger nicht. Dauert also noch bis zum Loopbacktest. Die Latenz lässt sich, so wie ich das mache (Loopback im Audiointerface) eh nicht so leicht bestimmen. Ich kann die zwar mit einem Audioprogramm auslesen, da steht aber dann genau das, was ich im USB-Device-Descriptor reingeschrieben hab. Dort muss man normal das angeben, was das Audiointerface selbst hat. Darauf wird dann noch das addiert, was die Blockgrößen in den USB-Paketen erzeugen und dann wirds angezeigt. Von abgespielter Datei nach aufgenommener Datei ist die Latenz über ein korrekt eingestelltes Interface eh Null, dafür sorgt die Latenzkompensation und die rechnet mit absoluten Samplepositionen mit der Korrektur, die im Descriptor steht. D.H. die Aufnahme schreibt an einer latenzkompensierten Position in der Datei. Deswegen macht man das normal andersrum, Digitalloopback im PC und von Analog nach Analog die Latenz messen. Dann sieht man die Latenz, die man in einem realen Echtzeitmix über das Interface und den PC hat. Kann ich ja dann auch mal machen. Interessant ist ja daran eigentlich auch nur, wie klein man die Puffer einstellen kann.
Peter Diener schrieb: > dass man die aufwändige Analogfilterung zur Bandbegrenzung dann > gegen nicht so steile Filter ersetzen kann, die dann weniger rauschen. ... die weniger zerren. Mit dem Rauschen hat es weniger etwas zu tun. > Im Rechner kann man die Bandbegrenzung vor dem downsampling dann in > 64 Bit praktisch rauschfrei rechnen. "die Bandbegrenzung rauschfrei rechnen" ??? Peter Diener schrieb: > Nur ganz wenige Produktionen laufen bis zum Master in der hohen > Samplingrate. was aber nur daran liegt, dass 90% der heutigen Produktionen von Amateuren gemacht wird. Ich darf Dir versichern, dass im profesionellen Bereich kommerzieller Produktion sehr wohl von den zetlichen Auflösungen Gebrauch gemacht wird und dies nicht nur bei der Aufnahme, sondern vor allem auch bei der Bearbeitung, insbesondere was das Einschleifen analoger Geräte anbelangt. > Und der Nutzen wird auch immer wieder angezweifelt. Was ebenfalls daran liegt, dass der Audiomarkt (Hersteller, Bastler, Nutzer und Höhrer) zu 99% nichts von technischer Signalverarbeitung verstehen. Die Wirkung erhöhter Sampleraten im Bezug auf die Güte von Filtern, deren Verzerrung und Sperrverhalten lässt sich mit Matlab, Octave und sogar Excel mit geringem Aufwand leicht verifizieren. Danach gibt es nicht mehr anzuzweifeln. :-) Die 96kHz werden nur deshalb nicht so konsequent durchgezogen, weil man am Ausgang der Signalkette Lautsprecher vorfindet, die derartige Klirrfaktoren präsentieren, dass der Nutzen von 96kHz beim Abspielen unter geht. In der Signalkette wird aber sehr wohl überwiegend mit 96k gearbeitet. Der Nutzen ist nur bei vielen Produktionen noch deshalb gering, weil heute viel mit Samples und Audio-CDs gemacht wird und dieses Ausgangsmaterial fast ausschließlich in 16Bit/44,1 vorliegt. Produktionen im akustischen Bereich (Klassik, Jazz etc) laufen mit voller Bandbreite. Peter Diener schrieb: > Dann sieht man die Latenz, die man > in einem realen Echtzeitmix über das Interface und den PC hat. genau um die geht es mir :-) Man kann sich allerdings auch ungefähr ausrechnen, wie lange man bei USB braucht, um 8 Kanäle Stereo bei 192kHz und 24 Bit seriell durchzuquetschen. Noch ein Hinweis: Meine Worte sollen natürlich nicht Deine Arbeit beeinflussen. Für Hobbyanwendungen ist das ja allemal tauglich. Allerdings sind gute analoge Frontends nicht so einfach zu bauen, auch wenn man die Wandler in 96kHz heute praktisch nachgeworfen bekommt. So ein gutes Analogfrontend könnte ich auch noch gebrauchen. Billige gibt es ja genug: http://www.thomann.de/de/behringer_ultragain_pro8_digital_ada8000.htm Ist zwar das Billigste vom billigen, aber durch einen Hobbyaufbau schon nicht so einfach zu toppen. Hier ist übrigens so etwas der Standard: 24Bit/192kHZ http://www.thomann.de/de/lynx_studio_aurora_8.htm Und der hat analog auch die Qualität, um die Auflösung zu rechtfertigen.
Wenn als Subset von "TDM" I2S oder I8S reichen, und Du nicht unbedingt drauf fixiert bist, selber den Mixer/Switch auf einem programmierbaren Baustein (FPGA) programieren zu wollen (würde schon mal etwas Komplexität aus dem Vorhaben nehmen), könnte vielleicht ein SDK (ev. auch Modul oder Chip, ist aber BGA) von www.archwave.net/solution.php eine Alternative sein, z.B. mit DM1100F. Das Teil hat genügend Resourcen für Dein Vorhaben, nämlich - I2S/SPDIF bis 192 KHz - I8S bis 96 KHz - ARM926E - addidional Audio-Processor - USB/FirwWire und ist auch in namhafte Geräte eingebaut. Weiss allerdings nicht, ob Du als "Hobby-Anwender" an die Dinger rankommst. Mal fragen kostet ja nix... ;-)
Danke für die ganzen Vorschläge, ich werd mir das alles Ende nächster Woche genauer ansehen. Im Moment hab ich leider recht wenig Zeit. Dann kommt auch der Loopbacktest. Grüße, Peter
Hallo Peter (& andere Foristen), gibt es inzwischen etwas neues zu deinem Projekt? Ich suche seit einiger Zeit nach einer Möglichkeit, vorhandene Audiointerfaces mit Firewire- und ADAT-Anschlüssen an einen Laptop ohne Firewire-Port (und ohne EpressCard-Slot o.ä.) anzuschließen. Da die Suche nach ADAT<->USB2.0-Bausteinen zunächst erfolglos war, hatte ich die Idee, in einem FPGA ein 16-kanaliges USB-Audio-Device abzubilden; externe Schnittstellen: 2x ADAT in, 2x ADAT out, evtl. Wordclock in. Allerdings bin ich auf dem Gebiet FPGA absoluter Neuling, und kann schlecht einschätzen, wie die Chancen stehen, dieses Projekt neben Job & anderen Hobbys einigermaßen zeitnah fertig zu bekomen. Duch peks Post bin ich auf den DM1500E gestoßen: http://www.archwave.net/files/8_Archwave_DM1500_Product_Info.pdf Mit dem sollte es doch mit überschaubarem Aufwand möglich sein, ein USB-Audio-Interface mit 4xADAT-in, 4xADAT-out und Wordclock-in zu entwerfen. (Und noch 'ner ganzen Menge an weiteren Optionen, aber daran bin ich derzeit nicht interessiert) Ich habe von archwave eine Preisauskunft und genauere Infos zum DM1500E angefordert und würde mich freuen, wenn ihr mir helfen könnt, ob so ein Projekt für einen ambitionierten Hobbybastler realisierbar ist, oder ob es noch Alternativen gibt (abgesehen vom PC mit Firwire-Anschluss und professionellen USB-Interfaces mit ADAT-Eingängen ;) ). Danke & Grüße Ladde
Ich hätte da Interesse, da ich auch noch ADAT für meine Sachen einrüsten möchte. Ich will das allerdinsg rudimentär auf low level Ebene, brauche also nur die Schaltung und das Protokoll. Was das Chip hier kann, überschaue ich noch nicht so 100%, es scheint mir aber etwas oversized, nur für einen ADAT-Input. Ich erinnere mich beim Anblick der Seite, dass ich den DM1500E auch schon mal ins Auge gefasst hatte, allerdings mir für meine Apps die CPU zu langsam und zu schwach im Verhältnis zu dem, was an Peripherie zu steuern wäre und auch steuerbar ist. Dann gibt es noch die Frage nach den Kosten: Für einen ADAT-link braucht man in Fulls speed auch die 192kHz und muss aufgrund der 48kHz ADAT-Spec alle 4 Kanäle verbraten. Dann meine ich, sind das ja auch nur 16 Bit je Kanal. Ich bräuchte also schon einmal 2 Chips. Eine Nachfrage bei denen hat damals ergeben, dass sie genau wissen wollten, was ich so mache und es wäre auf ein NDA hinausgelaufen. Da habe ich das aus verschiedenen Gründen zurückgestellt, obwohl man den Chip gfs als eine Art Frontend gebrauchen könnte. Mit dem DSD link sind es wohl 16 Kanäle mit 12.288 MHz, was ich als 2x32Bit x 192kHz intepretiere, mit denen man ans FPGA käme und alleine schon das Referenzboard wäre nutzvoll. Für eine "Nur-ADAT" ist das aber zu fett, denke ich. Das müsste in einem kleinen FPGA auch zu machen sein.
Der Cypress FX2 wurde in diesem Thread öfters genannt. Kennt jemand Projekte, die den Chip als USB-Audio-Bridge nutzen?
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.