Hi zusammen, ich suche ein passendes Board für meine Anlage. Ich habe mir zwar ein adsp-21369 geschossen befürchte aber dass ich damit ohne die teuren Lizenzen nicht weit komme. Daher nun in deinem neuen Thread die Frage nach möglichen Alternativen. Ich habe z.B. den ADAU1467 entdeckt, welche angeblicht auch völlig ausreichen würde (angeblich 24000 Taps bei 48khz). Kennt ihr noch weitere mögliche Chips welche für mich interessant sein könnten? Zudem die Frage, ob man die FIR-Filter durch ein Controll-Board zur Laufzeit anpassen kann? Bei dem adsp-sc589 sharen sich die Cores einen gemeinsamen Speicher, mit dem man derartiges realisieren könnte. Mein Wunsch wäre es, mehrere Presets zu speichern und ggf. per kleiner Web-App auf dem Controllerboard (z.b. einem raspi) anpassen zu können, um nicht immer den pc anschließen zu müssen. Freue mich über Meinungen und Anregungen!
> ohne die teuren Lizenzen nicht weit komme. Ja, P.G.H. > weitere mögliche Chips Für das stumpfe Abarbeiten von FIRs taugen eigentlich alle FPGA die Multiplizierer haben. > zur Laufzeit anpassen An den Koeffizienten zu drehen scheint ja erstmal kein Problem. Aber das ganze ohne störende Nebengeräusche hinzubekommen. > per kleiner Web-App Das klein soll wohl einfach suggerieren. Einfach wäre wohl ein separater Conroller, der sich um solchen Quatsch kümmert. Solange man Ethernet als einfach ansieht.
FPGAs habe ich nur noch ein MyRio von national instruments rummliegen... Wäre sowas ausreichend um damit 8 kanäle mit 2000 taps fir filter zu verarbeiten? Bei der Webapp, dachte ich an sowas wie einen ESP32, mit ner kleinen Webseite, auf der man txt, hochladen kann, welcher der ESP dann nutzt um die Filter zu rekalibrieren.
> ein MyRio von national instruments Das kenne ich nun nicht. Aber ein Cyclone II EP2C5T144C8 sollte für einige Meter FIR-Filter reichen. Die Multiplizierer muss man per Pipeline und Sharing benutzen. Für ein Resultat braucht der aber auch nur 4 ns. Wie viel das fertige Design belegt, sagt einem die Software ja, und wenn es nicht passt, muss man entweder einen grösseren oder mehrere FPGA nehmen. > 8 kanäle mit 2000 taps Ja, das wären grob gerechnet in der Summe 16 k Koeffizienten und für den kleinsten Cyclone II schon etwas zu viel :). Aber warum sollten ein paar Bandpässe nun 2000 Taps brauchen? Das kommt mir ein wenig reichlich vor. Schau dir die vorhandenen Resourcen eines kleinen FPGA an, und dimensioniere die Filter so, dass sie da hineinpassen. Für die Koeffienten sind das der vorhandene Speicherplatz und für das Gesamtdesign die Anzahl und Breite der Multiplizierer. Das rechne dir mal selber aus...
Das MyRio Board hat einen Zynq-7000 drauf. Mit dem wollte ich damals meine ersten Versuche mit FPGA-s machen und Labview. Man kann das Board aber auch mit anderen IDE's programmieren. Wäre daher auch spannend, ob der ausreichend power hätte für sowas? Wlan ist auch eingebaut, wäre also nur noch die Frage als Leihe, welchen ADC und DAC ich da anschließen muss und vor allem wie^^ für ein 8 in + 8 out cinch. Kennt ihr da ein gutes Board, was man verwenden könnte als ADC un/oder DAC? Bzw. erstmal die Frage ob der Zynq genug power für sowas hätte?!
Simon F. schrieb: > Mit dem wollte ich damals > meine ersten Versuche mit FPGA-s machen und Labview Argh! Labview ist zu allem gut, aber nicht zum FPGA entwickeln! Dann lieber noch die Blöckchen vom Xilinx oder die aus Simulink. >Re: Welches DSP für 7.1 FIR-Filter Mit 7.1 ist wohl 7.1 Surround gemeint? Braucht es da besondere Filter?
Ja dachte ich mir schon^^ Aber man kann den Zynq ja auch ohne Labview programmieren =) 7.1 --> Genau, es geht um eine Audioanlage und nein, außer IIR und FIZ-Filter brauche ich da keine besonderen Filter^^
Kennt einer von euch ein adc/dca Board mit cinch anschlüssen für 2-8inputs und 8 outputs, was man an den fpga anschliesen kann? Mindestens 24bit gerne auch 32bit.
Die wohl entscheidende Frage ist, was das Filter denn tun soll und weniger, mit welcher Technologie es realisiert wird. Simon F. schrieb: > 24000 Taps bei 48khz Die braucht man wohl nicht, weil man so bis etwa 2Hz runter gelangt. Üblich sind eher Sparversionen bis Lamba/4 und dies auch nur runter bis 16Hz etc. was auch mit 1024 TAPs noch zu machen ist. Die genannte Konstellation bräuchte es bei 8 Kanälen auch 9Mia Operationen. Sicher, dass das so stimmt? Um das mit einem billigen FPGA zu machen, würde man 96kHz und 4096 TAPs in 16 Einheiten arbeiten, die auf knapp 50MHz laufen und mit MULs in fabric laufen können. Für ein 8 Kanalsystem wäre dann in einem Spartan 3 noch genug Platz. In 48kHz kriegt man sogar noch AGC unter, um einen MBC zu bauen: http://www.96khz.org/htm/multibandcompressor.htm Mit einem heutigen FPGA würde man auf 200MHz bauen. Der DrumComputer im Artix arbeitet an zwei Stellen mit einem "langen" FIR-Filter. Wieder 16 Einheiten, dafür mit 32768 TAPs und 768kHz Rate. Die Bässe (z.B. den .1-Kanal) bearbeitet man zweckmäßigerweise aber mit einen IIR. Erzeugen kann man sie per PDM. Simon F. schrieb: > Kennt einer von euch ein adc/dca Board mit cinch anschlüssen für > 2-8inputs und 8 outputs, was man an den fpga anschliesen kann? Kommt auf die geforderte Qualität an. Die meisten erschwinglichen Wandlersysteme arbeiten auf USB. Was du fürs FPGA brauchst, ist aber TDM oder S/PDIF mehrkanalig, also z.B. ADAT. Das jeweils zu wandeln ist nicht so easy bzw die Wandler mit TDM Ausgang sind in der höheren Preisklasse. Das einfachste für dich sind wohl Chinamodule aus der Bucht, die parallel 2 Kanäle auch S/PDIF oder auch I2S wandeln und zurück. Die kosten so 6 .. 10,- das Stück. Macht geschätzte 70,- für 4 Ein- und 4 Ausgangsmodule. Es braucht dann aber etwas Fummelei mit den M256 Takten bei den Eingängen, um sie synchron zu bekommen oder du brauchst resampler.
Meinst du sowas dann? https://www.ebay.de/c/572676182 Wie meinst du das mit dem Gefummel mit dem synchronisieren? Da ich mit FPGA's noch nichts gemacht habe, kennt einer von euch ein passendes Beispiel-Repo, welches mit FPGA's auf i2S DAC/ADCs zugreift an dem man sich orientieren kann?
Simon F. schrieb: > Wie meinst du das mit dem Gefummel mit dem synchronisieren? Die Eingabe-Boards haben ihren eigenen Taktgenerator. Den muss man händisch synchen. I2S-IF gibt es eines auf OpenCores.
Eventuell 2x (ein teensy 4.0 mit 2xAudio Shield) gibt 8 mal rein und raus (16 bit, 44100 Hz ). Lässt sich damit "programmieren": https://www.pjrc.com/teensy/gui/index.html Mein "Spielzeug" fürs dieses Wochenende. Evtl. kann ich Montag mal berichten.
Ich hatte mal geschaut. DAC's gibt es recht hochauflösende für wenig Geld. Teilweise sogar mit 32bit und 384khz für gerade mal 3-6€. Ich finde aber kein Board mit einem adäquaten ADC dazu. Kennt einer ein 2 Kanal Board mit 32bit Adc's ähnlich diesem 24bit Board? https://www.audiophonics.fr/en/diy-dac/adc-analog-to-digital-converter-akm5720-i2s-24bit-96khz-p-13351.html Stereo-Input würde vorerst ausreichen für die ersten Versuche.
Angehängte Dateien:
-
i2sconverter.jpg
88 KB
Billiger, als der o.g. wird nicht unbedingt besser. Einen echten 32Bit-ADC gibt es so nicht. Du kannst froh sein, wenn du eine Analogqualität von 20 Bit reinbekommst. Als einfachste Lösung hätte ich den hier. Richtig gute Wandler musst du selber bauen oder zu entsprechenden Preisen erwerben. Ich habe u.a. ein fireface im Gebrauch. Von MINDPPRINT gabe es früher mal plugin Module mit 96kHz-Wandlern. Von denen hatte ich auch schon welche verbaut.
Ich hatte eine alternative Idee. Um mir die AD/DA Wandlung zu sparen, würde ich gerne versuchen das Audio-Signal direkt mit dem HDMI-Stream verarbeiten. Hat einer von euch schonmal mit sowas experimentiert? https://www.ebay.de/i/253942341747?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=253942341747&targetid=529282737297&device=c&mktype=pla&googleloc=9041877&poi=&campaignid=1669295905&mkgroupid=63847510759&rlsatarget=pla-529282737297&abcId=1139676&merchantid=138409015&gclid=CjwKCAiAzanuBRAZEiwA5yf4uiEnTbfTQ_Ls3MEHwF_BHnwsp77TrtDHJVYLxZk1a7kwhj8yKkK29RoCYn8QAvD_BwE Zudem die Frage, ob es einen Beispielcode gibt, zum das Audio und Video-Signal abzugreifen? Meine Idee, zwei dieser Board zu nutzen um das HDMi Signal abzugreifen, zu verarbeiten und anschließend das verarbeitete Signal an den AV-Receiver weiterzuleiten.
Alternativ dazu: https://www.ebay.de/itm/HDMI-MHL-to-IIS-I2S-HDMI-IIS-I2S-Separate-Extract-Audio-I2S-DSD-Optical-Coaxial/123962902103?_trkparms=aid%3D555021%26algo%3DPL.SIMRVI%26ao%3D1%26asc%3D40735%26meid%3D5d732c4fc4004a2c8fb753d13a8e444e%26pid%3D100752%26rk%3D2%26rkt%3D8%26mehot%3Dco%26sd%3D253942341747%26itm%3D123962902103%26pmt%3D1%26noa%3D0%26pg%3D2047675&_trksid=p2047675.c100752.m1982 Was denkt ihr wie groß wird das Delay des FIR Filters mit dem FPGA? Wenn das nicht nennenswert groß ist, wäre das eine einfachere Lösung, da ich nicht mit dem HDMI-Protokoll rumm hantieren müsste :D
Moin, Simon F. schrieb: > Hat einer von euch schonmal mit sowas experimentiert? > Ebay-Artikel Nr. 253942341747 Wenn du da mit einem HDMI Signal reingehst und damit tatsaechlich I2S rausextrahierst, dann solltest du sofort auch Lotto spielen. Simon F. schrieb: > Alternativ dazu: > Ebay-Artikel Nr. 123962902103 Damit koennte es evtl. gehen, Audio aus einem HDMI Link rauszufieseln. Aber nicht wieder rein. Simon F. schrieb: > Was denkt ihr wie groß wird das Delay des FIR Filters mit dem FPGA? Naja, das wird wohl stark von der Laenge/Gruppenlaufzeit deines ollen Filters abhaengen. Wenn du das nicht weisst, wie willst du dann irgendwas filtern? Gruss WK
ok dann bestätigt das meine Befürchtung, aber dann versuche ich das mit dem HDMI/MHL Board. Mit den Filtern beschäftige ich mich dann wenn ich ans Coden gehe :D Wie komme ich am besten von dem FPGA mit 8 Kanälen digital an den AV-Receiver? https://www.de.onkyo.com/de/produkte/tx-nr808-35420.html
oder gibt es alternative Möglichkeiten, um video und audio von hdmi zu verarbeiten auf dem FPGA und dann wieder hdmi asuzugeben?
:
Bearbeitet durch User
Moin, Simon F. schrieb: > Wie komme ich am besten von dem FPGA mit 8 Kanälen digital an den > AV-Receiver? https://www.de.onkyo.com/de/produkte/tx-nr808-35420.html Keine Ahnung ob ueberhaupt. Und schon garnicht, wie am besten. Woher hast du denn ploetzlich 8 Kanaele? Wenn du aus deinem HDMI ein einzelnes, popeliges Stereopaar rauspfriemeln kannst, dann laeufts schon bombig... Kanns sein, dass das alles eine Nummer zu gross ist? Gruss WK
Sehr gut möglich, aber ohne große Ziele lernt man auch nichts! =) Ich habe gerade das PYNQ-Z1 und -Z2 gefunden, was bereits einen eingebauten HDMI in und out hat. Leider scheint die api aber nur video vorzusehen. Ich überlege gerade ob ich das MyRio nicht verkaufe und ein anderes Board kaufe, was mir den Hardwarepart abnimmt, damit ich mich nur um die Software kümmern muss. Jemand eine Idee für ein alternative Board, welches HDMI einen in- und output hat? PS: 8 Kanäle brauche ich, da ich 4 Zweiwege Boxen mit Stereo anfahren möchte (Semi-Surround). Daher auch die Anforderung mit der Filterung. Aktuell nutze ich dazu ein Sure DSP, möchte das aber gerne komplett digitalisieren bis zum AV-Receiver und erst dort dann die eingebauten DAC's nutzen. So spare ich mir unnötige Klangverluste durch hin und her wandeln. Die Idee mit dem FPGA, war mich mit dem Thema auseinandersetzen zu müssen, da ich bisher nie was mit FPGA's gemacht habe und das gerne lernen möchte, aber ich gebe dir Recht, zusätzlich noch Hardware-Layouten zu müssen oder ähnliches würde das Vorhaben zu komplex machen. Freue mich über alternative Vorschläge!
Moin, Hast du denn schon irgendwelche Filter am Laufen gehabt? So richtig, mit Krach ausm Lautsprecher und nicht nur simuliert? Ansonsten muss dir bei HDMI klar sein, dass da immer auch mal der HDCP zuschlagen kann. Und dann guckst du auch mit irgendwelchen PYNQ oder STYNQ Boards etwas bedroeppelt. Gruss WK
Doe Boxen sind aktuell aktiv getrennt. Nur leider über den AD DA umweg über ein sure dsp aktuell. Den analogen Schritt würde ich gerne ungehen, daher die idee das Audiosignal digital vorzuverarbeiten aus dem HDMI und dann digital an den AVR. Wie ich das digital verarbeite ist mir egal, hauptsache keine verlust behaftetr AD wandlung dazwischen.
Neue Idee: Ich nehme einen HDMI-Audio-Extraktor. Dieser liefert mir das Audio-Signal auch digital per Toslink. Dann verarbeite ich dieses und spiele es per Toslink weiter an den AVR. Würde das das Problem lösen mit dem HDMI Problem? Oder ist das aus dem optischen Anschluss kommende Protokoll, ebenfalls schwierig zu verarbeiten? https://www.reichelt.de/hdmi-4k2k-7-1-audio-extractor-goobay-58967-p218617.html
Moin, Simon F. schrieb: > Würde das das Problem lösen mit dem HDMI Problem? Keine Ahnung wie/ob der mit HDCP zurechtkommt oder zurechtkommen muss. > Oder ist das aus dem > optischen Anschluss kommende Protokoll, ebenfalls schwierig zu > verarbeiten? Wird wohl von der Datenrate her schonmal angenehmer sein als HDMI; wenns was anderes als PCM-Stereo ist,(Dolby,AC3-gedoens) kann's decodieren auch unangenehm werden. Wuerde es aber bei HDMI dann auch. Gruss WK
Kennt jemand vergleichbare Projekte an denen ich mich orientieren könnte? Ich denke mit dem Stereo Signal käm ich auch aus erstmal, auch wenn das mehrkanal Signal natürlich auch interessant wäre^^ Vor allem die Anbindung eines optischen Kabels an den FPGA würde mich interessieren. Denn weder das pynq-Board noch das MyRio haben einen optischen Eingang und bei den Boards für Raspis und ähnlichem über I2S finde ich keine Beispielcodes in den Dokus. Daher die Frage wie ich aus den Dingern das Signal auslesen kann?! Danke btw. für die vielen Antworten =)
Simon F. schrieb: > Neue Idee: Ich nehme einen HDMI-Audio-Extraktor. Ja, so etwas funktioniert. Habe ich hier. Da steckt auch ein ähnlicher Chip drin, wie der in deinem Beitrag von weiter vorn. Der extrahiert aber nur Stereo und kein 8-Kanal, sondern nur 2 Kanal über S/PDIF. Da gehen auch nur 2 Kanäle. Mir ist auch keine Anwendung bekannt, die 8 Kanal Audio erzeugt und weiterleitet und schon gar nicht über HDMI.
Ja ich denke stereo Inout reicht. Was ich dann aber machen möchte wären 8 Kanäle weiter zu leiten digital (4x 2wege Lautsprecher aktiv getrennt und entzerrt). Werde das mal bestellen und dann mal rumm probieren. Jemand mal mit spdif und fpga gearbeitet? Ein beisßiel projekt wäre toll oder eine Lib die das decodiert :)
So Arty z-20 bestellt (gabs bei amazon für 130 als Rückläufer). Seit Februar kann man oer xilinx IP wohl auch 8 kanal audio von hdmi trennen :) https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_tx_ss/v3_1/pg235-v-hdmi-tx-ss.pdf&ved=2ahUKEwj-h-W3pO7lAhX6wAIHHVNPB6wQFjAAegQIAxAB&usg=AOvVaw377AWudEOr5w5KNS7rllpk Ich lasse mich mal überraschen ob das klappt^^ Jemand bereits testen können was aus der IP raus kommt und ob das sinnvoll weiterverarbeitbar ist?
Moin, Simon schrieb: > Seit > Februar kann man oer xilinx IP wohl auch 8 kanal audio von hdmi trennen > :) Was kost' der denn? Gruss WK
Wenn ich das richtig sehe ist das beim webpack dabei. Gibt zumindest auch ein zwei Beispiele für das Arty Board.
Simon schrieb: > xilinx IP wohl auch 8 kanal audio von hdmi trennen Die fetten und überladenen XI-IPs können sicher auch Kaffee kochen. Simon schrieb: > Wenn ich das richtig sehe ist das beim webpack dabei. Ja, aber als "purchase" > Gibt zumindest > auch ein zwei Beispiele für das Arty Board. Schon ausprobiert? Die Beispiele haben ja oft so ihre kleinen Problemchen, wenn man sie ernsthaft in Verwendung bringen möchte. Ich erinnere mich noch bestens an die Aussage eines XI-FAEs, der auf die Frage nach der Verwendbarkeit mit der Aussage kam, die Beispiele seien "nur zur Ansicht" und "nicht für die direkte Verwendung in kommerziellen Projekten gedacht". Das Zeug ist nicht voll getestet, nicht verifiziert und muss immer erst umständlich in Besitz genommen werden. Dergute W. schrieb: > Was kost' der denn? Wäre zu erfragen. Ich habe dafür keinen echten Bedarf, würde mich aber stark interessieren, was man dafür ausgeben muss. Ich empfehle lieber, sich eines der Hobbyprojekte anzutun und diese anzupassen. Kostet nichts, besser supported, frei von Rechten etc. Für kommerzielle Projekte muss man so wie so selber ran, da der Core nie das kann, was man selber genau braucht.
Joa, das Board ist gerade im Zulauf, dann wird getestet. Nächste Updates dann wenn das Board da sind :)
Rolf S. schrieb: > über S/PDIF. Da gehen auch nur 2 Kanäle. Hängt von der Frequenz ab. Ich sende z.B. bei meinem Synth über S/PDIF im Standard 192kHz x 2 durchaus 8 Kanäle mit 48kHz, ähnlich wie ADAT das macht. Der FPGA im Receiver-PCB muss es halt wieder raussortieren. > Mir ist auch keine Anwendung bekannt, die 8 Kanal Audio erzeugt Ich (und noch andere Elektronikmusiker) produzieren sehr wohl 8 Kanal Audio: Auch die Produktionssysteme der DAWs unterstützen das seit geraumer Zeit. Es wird natürlcih vorwiegend live und als Setup für Surroundmischungen verwendet. > und > weiterleitet und schon gar nicht über HDMI. HDMI kann schon seit der SPEC 1.0 8 Kanal Audio, seit der 1.4 HBR 768kHz und seit der 2.0 1536kHz, also 32 Kanäle mit 48kHz oder eben die 768kHz x 8. Es ist allerdings richtig, dass es noch kaum Geräte gibt, die das auslasten.
Hast du dazu vll ein Beispielprojekt an dem ich mich orientieren kann? :)
Lol.... Das HDMI 1.4/2.0 IP von Xilinx wird vom arty nicht unterstüzt.... Jetzt habe ich ein anderes Board bestellt für welches das IP funktioniert... Was ein Krampf -.-
Mimas Artix 7 heist das Board welches das IO unterstüzt... Werde berichten wenn es da ist!
Angehängte Dateien:
-
i2s_via_hdmi.gif
19 KB
Ob das was wird? Hast du auch kurz nachgesehen, was du dafür alles benötigst? Der IP-Core von Xilinx braucht Transceiver-Ports. Sind die in den Chip vorhanden? Haben sie die ausreichende Geschwindigkeit? Der Biespiel-Code zu dem Projekt ist der bekannte (sehr einfache) Code von Hamsterworks, gebaut für direkte TMDS-Pegel über buffer und 640x480@60Hz. https://numato.com/kb/hdmi-output-example-design-using-vivado-for-mimas-a7-fpga-development-board/ Die eigentlichen HD-Auflösungen wirst du damit weder senden, noch empfangen können, fürchte ich und für das Herausholen der Audiodaten aus dem Video wirst du deutlich mehr brauchen, als nur den Hamster-Code. Ich habe auch den Verdacht, dass hier eventuell noch ein kleines Misverständnis bezüglich Audio über HDMI herrschen könnte, denn unlängst ist mir bei der Frage, ob man nicht allemöglichen Daten über HDMI-Kabel übermitteln könnte, dies hier in die Hände gefallen: Die Schaltung sieht mir aber so aus, als ob nicht Audio im Video - sondern stattdessen Audio anstatt Video von deinem Audio-Receiver kommen könnte. Siehe auch: Beitrag "Analoger Mehrkanaton zu HDMI" Wo sind die Audio / Video-Experten?
Puh mit der Frage bin ich als FPGA-Anfänger überfragt^^ Ich kann dir nur die Links zu den Dokus hier geben: https://numato.com/docs/mimas-artix-7-fpga-development-board-with-ddr-sdram-and-gigabit-ethernet/ und das ist der eingesetzte HDMI-Buffer: https://assets.nexperia.com/documents/data-sheet/IP4776CZ38.pdf Laut Vivado wird zumindest das IP-Core HDMI 1.4, 2.0 unterstützt. Ob das nun heißt dass man da auch tatsächlich Audio raus und rein bekommt, weiß ich allerdings nicht^^
Moin, Simon schrieb: > Ob das > nun heißt dass man da auch tatsächlich Audio raus und rein bekommt, weiß > ich allerdings nicht^^ Wuerde ich eine grosse Xilinx-FAE-Kappe tragen, wuerde ich natuerlich sagen: Selbstverstaendlich klappt das und das aus dem IP-Core Datenblatt pg236 zitieren: "The audio interface is a 32-bit AXI4-Stream master bus. The subsystem converts the captured audio to a multiple channel AXI audio stream and outputs the audio data on this interface." Aber wenn ich meine kleine Entwicklerwurst-Kappe trag', und mir kommt einer mit so einer Aussage, dann weiss ich dass das jetzt nicht technisch voellig unmoeglich sein wird, aber bis das dann mal fliegt, doch ganz schoen Zeit ins Land gehen wird... Gruss WK
Naja, dann hab ich mir ja schön was vorgenommen :D Aber ich nehme die Herausforderung an! Mehr wenn das Board da ist und dke ersten Tests gemacht wurden :)
Dergute W. schrieb: > Wuerde ich eine grosse Xilinx-FAE-Kappe tragen, Bei Xilinx-FAEs gilt: Große Kappe und große Klappe. Theoeretisch geht bei denen alles, im Detail aber nahezu nichts, ohne daß man es korrigiert. Mir ist in 10 Jahren FPGA-design noch kein einziges Demo untergekommen, das vollständig funktioniert hätte. Meistens fehlen irgendwelche Informationen wie constraints, files oder ganze Pins. Beschreibungen und Rücksichtnahmen auf erweiterte Anforderungen fehlen gänzlich und man hat Einschränkungen: Beitrag "DDS Compiler - Phase nur bis 16 Bit?" Dergute W. schrieb: > aber bis das dann mal fliegt, > doch ganz schoen Zeit ins Land gehen wird... Nur solange man das so verwendet, wie es der Erzeuger sich gedacht hat, ist das fein und einfach. Aber etwas Ändern und an eigene Bedürfnisse anzupassen, macht Arbeit und geht bisweilen auch schön schief. In der Zeit hat man das Meiste auch selber erledigt und zwar in ordentlich.
Simon schrieb: > Laut Vivado wird zumindest das IP-Core HDMI 1.4, 2.0 unterstützt. Ob das > nun heißt dass man da auch tatsächlich Audio raus und rein bekommt, weiß > ich allerdings nicht^^ Die 1. Frage ist nicht, was aus dem Core kommt, sondern was aus deiner Anlage kommt! Ich hatte oben eine Schaltung angehängt, die ich gefunden hatte mit der Suche nach Alternativen für differentielle Datenübermittlung. Beitrag "Re: Audio mit HDMI übertragen" Eigentlich ist es dasselbe wie Ethernet: 4 Diff-Leitungen. Displayport und Cameralink arbeiten so ähnlich, glaube ich. Aber es kommt alles auf das Protokoll an, wie man sieht. Der Empfänger muss es auch verstehen. Du wirst also deine Bedienungsanleitung herauskramen und nachlesen müssen. Ergebnis? Was ich über Audio im Video sagen kann: Man kann es offensichtlich darin verpacken und meine Soundkarte kann hier z.B. den Sound zum TFT-Monitor schicken. Nennt sich im Windows "NVIDIA Audio Device". Parallel dazu liegen als Option die Soundkarte und der onboard Sound. Also kann der NVIDIA-Treiber irgendwie den Klang vom Windows-Sound-Manager in den Videostream packen, vermutlich in die Austastlücke. Wer das real tut, weiß ich nicht. Ich nehme an, es macht der Intel-Core im Prozessor mit seiner MMX-Unterstützung oder im anderen Fall ein NVIDIA-spezifischer Grafikprozessor auf der Karte. Die Daten dürften in beiden Fällen per PCIe angerauscht kommen. Der Monitor muss es dann wieder auspacken. Vermutlich macht er das in einem ASIC. Ob das der Xilinx Core auch kann, darf bezweifelt werden. Und wenn wie ich es kenne, von den AV-Playern gar kein Video kommt, sondern Audio im o.g. Standard, dann müsste der Core es erkennen und umschalten, oder von Anfang an dafür eingestellt werden. Wenn ich den anklicke, sehe ich da aber nichts in der Richtung. Vielleicht solltest du mit soetwas anfangen: Beitrag "HDMI mit FPGA analysieren" Vielleicht gibt es aber Audio-DSP-Systeme, die das Format direkt lesen können.
Naja ich halte es mir noch offen das Audiosignal über den HDMI raus zu leiten. Ich denke ich bin schon froh wenn ich erstmal audio und video getrennt bekomme. Dann sehn wir weiter. Es bleibt ja noch die möglichkeit einen digitalen audioausgang zu nutzen, oder gar einen hdmi zu Audio+hdmi splitter vorzuschalten und dann nur das digitale Audiosignal zu verarbeiten. Aber wrstmal bleibt das wunschziel alles über hdmi zu machen.
Du scheinst nicht zu verstehen, was ich schreibe. Du hast hier wahrscheinlich keine Wahl. Entweder sendet deine Quelle so oder sie sendet anders. Daran muss du dich anpassen. Und wenn er es als Audio sendet, gibt es nichts zu trennen oder irgendwie "auszuleiten".
Also als Quelle wird in meinem Fall zunächst der FireTV Stick genutzt werden, welcher dann durch MeinGerät (FPGA oder Splitter + FPTA) geleitet werden wird und anschließend zu meinem AVR läuft. Erst danach kommt dann der TV. Heißt ich erhalte erstmal das vollständige Signal vom FireTV-Stick und werde im ersten Schritt versuchen dieses vollständig zu verarbeiten auf dem FPGA. Sollte das nicht gelingen, werde ich das FireTV-Signal splitten und nur mit dem digitalen Audio-Signal arbeiten. Dann hätte mir aber wahrscheinlich auch ein kleinerer FPGA gereicht^^ aber wir werden sehen. Da das Board aus Indien kommt, verzögert sich die Anlieferung...
Moin, Simon F. schrieb: > Also als Quelle wird in meinem Fall zunächst der FireTV Stick genutzt > werden, Puuuuh, wenn das mal HDCP maessig bloss gut geht. Da hab' ich doch erhebliche Zweifel... Gruss WK
Hm naja auch dafür gibt es angeblich IPs^^ https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.xilinx.com/support/documentation/ip_documentation/hdcp22/v1_0/pg249-hdcp22.pdf&ved=2ahUKEwjG3tDqzf3lAhXE3KQKHZ5tCwMQFjAAegQIBRAB&usg=AOvVaw1hrilTreHVFtZTZXQkLm8t Aber wir werden sehen was davon tatsächlich funktioniert :D
ansonsten gibt es hardware hdcp splitter, die den Schutz umgehen: https://www.amazon.com/gp/product/B004F9LVXC/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=grtv04-20&camp=1789&creative=9325&linkCode=as2&creativeASIN=B004F9LVXC&linkId=407e22fe9e12aa08c54832728a042835
Ich würde einen 20,- Euro HDMI-Audio-Splitter verwenden, der AC3/DTS über S/PDIF abtrennen kann. Ligawo hat solche Splitter. Wenn das Audio wirklich als HBR kommt, kann man es im FPGA aber auch direkt auswerten. Dazu braucht man keinen Xilinx-Core, jedenfalls keinen kostenpflichtigen. Es ist ja letzlich I2S, siehe HDMI-SPEC1.4.
Meint ihr man kann hdcp nicht direkt im fpga verarbeiten? Ich meine 20€ sind kein geld, aber wäre schon schöner wenn man allInOne ungesetzt bekommen würde :) Keiner Erfahrungen gemacht damit? Die i2s Variante kst natürlich einfacher und sicher ein weg den ich gehen werde wenn ich das mit dem hdcp decrypting nicht hinbekomme.
Vielleicht solltest du dir überlegen, was dieser Abschnitt aus der verlinkten HDCP-IP-Core-Doku für dich bedeutet: HDCP device keys are not provided with the reference design(s) and are not available from Xilinx under any circumstances. Customers who use the IP and reference design(s) to implement HDCP must become an HDCP Adopter and acquire device keys directly from Digital Content Protection, LLC. Failure by customers to do so will render the IP and reference design(s) incapable of successfully completing the HDCP implementation in customer products.
I see... Naja ich habe mir mal einen Splitter bestellt, dann kann ich ich beides testen und sehn was passiert :)
Ist ja interessant, ich habe mich in den letzten Wochen mit ähnlichen Themen befasst, da ich in Zukunft meine Lautsprecher per digitaler Frequenzweiche (+Raumkorrektur) und Tri-amping ansteuern möchte. Simon F. schrieb: > Kennt einer von euch ein adc/dca Board mit cinch anschlüssen für > 2-8inputs und 8 outputs, was man an den fpga anschliesen kann? > > Mindestens 24bit gerne auch 32bit. 8-Kanal DAC Boards gibt es z. B. von miniDSP. Einen passenden 8-Kanal ADC haben sie nicht separat, das gibt es dann auf ihren grossen Boards zusammen mit ihren DSP Lösungen. Ich habe mir ein paar Tage lang ihre Lösungen durchgesehen, für FIR Filter sind aber nur wenige schnell genug. Der OpenDRC kann 2-Kanal SPDIF auf 8-Kanal analog oder digital Filtern: 48kHz processing (Max 9600 taps total / Max 2048 per ch) 96kHz processing (Max 3400 taps / Max 2048 per ch) Ich habe dass dann wieder verworfen, da ich das ganze zu eingeengt finde, ist aber sicherlich eine gute erprobte (HW) Lösung, bei der man sich gleich auf den Filterentwurf konzentrieren kann. Rolf S. schrieb: > Simon F. schrieb: >> Neue Idee: Ich nehme einen HDMI-Audio-Extraktor. > > Ja, so etwas funktioniert. Habe ich hier. > > Da steckt auch ein ähnlicher Chip drin, wie der in deinem Beitrag von > weiter vorn. Der extrahiert aber nur Stereo und kein 8-Kanal, sondern > nur 2 Kanal über S/PDIF. Da gehen auch nur 2 Kanäle. > > Mir ist auch keine Anwendung bekannt, die 8 Kanal Audio erzeugt und > weiterleitet und schon gar nicht über HDMI. Es gibt von diesen HDMI-Audio-Extraktoren auch Versionen die gleich alle acht Kanäle extrahieren. Ich habe mir mal einen solchen bestellt und werde den dann mal durchtesten ob der (unerwünschtes) downsampling oder sonst wie Zicken macht in einem typischen AV Umfeld mit Blueray Playern/FireTV Sticks etc. Simon schrieb: > Meint ihr man kann hdcp nicht direkt im fpga verarbeiten? Ich meine 20€ > sind kein geld, aber wäre schon schöner wenn man allInOne ungesetzt > bekommen würde :) Ja, das geht schon. Die HDCP Keys (glaube bis 1.4) sind ja auch seit ein paar Jahren geleakt. Für Video und Audio Verarbeitung zusammen gibt es z. B. die NeTV2 Plattform: https://www.crowdsupply.com/alphamax/netv2 Aber da du "nur" Audio verarbeiten möchtest, rate ich dir dringend davon ab überhaupt etwas mit dem Video anstellen zu wollen. Der Aufwand explodiert gerade zu... So, jetzt aber dazu wo ich mit meinen Überlegungen gerade stehe. Moderne CPUs sind höher getaktet und multi-Core ist schon fast Standard, bieten also für gleiches Geld viel mehr nackte Rechenleistung als ein (Audio)DSP und sind viel einfacher in der Handhabung als FPGAs. Mein 2. Schritt nach dem Austesten des Extraktors wird also sein, aktuelle Quad-Core Raspberry Pis zu testen, wie lange FIR Filter darauf laufen können und ob die existierenden Open Source Convolver multi-Core Systeme ausreizen können ohne die Kanalsynchronisation zu verlieren. Meine Kette soll dann so aussehen: Quelle -> HDMI-Audio-Extraktor -> I2S Eingang am Raspberry Pi -> Filterung in ALSA mit LADSPA Plug-ins -> 8-Kanal Audio Ausgabe per HDMI -> 7.1 AVR -> Lautsprecher Es gibt gute Tutorials wie man mit einem Raspberry Pi 1 und IIR Filtern digitale Frequenzweichen bauen kann: rtaylor.sites.tru.ca/2013/06/25/digital-crossovereq-with-open-source-sof tware-howto/ Und dazu lange Diskussionen mit vielen Tipps bei diyaudio (Jürgen S. hat da auch mitgeholfen :-)) https://www.diyaudio.com/forums/pc-based/274331-ladspa-plugin-programming-linux-audio-crossovers.html https://www.diyaudio.com/forums/twisted-pear/277564-ladspa-filters-digital-crossovers-bbb.html Wie gesagt, dass sind alles IIR Filterlösungen und ich will herausfinden, ob das ein paar Jahre später nun auch mit FIR Filtern möglich ist z. B. mit einem dieser FIR Convolver: https://www.ludd.ltu.se/~torger/brutefir.html https://github.com/bmc0/dsp Simon F. schrieb: > Was denkt ihr wie groß wird das Delay des FIR Filters mit dem FPGA? Wenn > das nicht nennenswert groß ist, wäre das eine einfachere Lösung, da ich > nicht mit dem HDMI-Protokoll rumm hantieren müsste :D Die Doku zu BruteFIR ist sehr Umfangreich, war interessant zu lesen. Da gibt es auch eine Tabelle, Rechenleistung vs. Latenz. BruteFIR kann Filter partitionieren, was die Latenz verkürzt aber mehr Rechenleistung benötigt. Ich gehe davon aus, dass ich mit diesem cheap-diy Ansatz schon genug Zeit verbasteln werde :-) Kritische Komponente bleibt der HDMI-Audio-Extraktor, darum wird der vorgängig getestet. Hoffe der kommt noch vor den Feiertagen an...
Christoph Z. schrieb: > Moderne CPUs sind höher getaktet Wie hoch sind die getaktet und (wichtiger) parallelisiert, damit das effektiv funktioniert? Denn: Christoph Z. schrieb: > 96kHz processing (Max 3400 taps / Max 2048 per ch) 96000 Samples erfordern bei 3400 TAPs und "normaler Konfiguration" eines symmetrischen FIRs 48000 Additionen für die Spiegelung sowie anschließend noch 48000x3400 Multiplikationen. Das wären 165 Mio Operationen. Mit einem 1GHz ARM macht man das auch, ist aber ziemlich zu. Ich nehme an, die haben spezielle HW-Einheiten, die das machen?
Markus W. schrieb: > Das wären 165 Mio > Operationen. Mit einem 1GHz ARM macht man das auch, ist aber ziemlich > zu Ich hätte jetzt angenommen, dass da mehr drin liegt, da die besseren ARMs ja alle Muliplizierer und DMA drin haben. 165 Mio Operationen sollte im Prinzip ja schon mit einem Cortex-M4 erreichbar sein. Hast du da praktische Erfahrung? Was limitiert die Performance beim ARM? Oder ist es generell, dass da die Speicherlatenz noch so viel Zeit kostet? Markus W. schrieb: > Ich nehme an, die haben spezielle HW-Einheiten, die das machen? Der DSP im miniDSP OpenDRC ist ein Analog Devices ADSP21369 mit 333 MHz, 32 bit floating point und nach Marketing 2,4 GFLOPS. Ein grosser Unterschied ist, dass der DSP HW zur Sample-rate-conversion (SRC) drin hat. Gemäss den Erfahrungen mit dem BeagleBone kostet SRC mehr Rechenzeit als alle IIR Filter. Das kann mit ALSA aber vermieden werden wenn entweder die Plug-ins unabhängig von der Samplerate sind oder separate Filterketten definiert werden.
Christoph Z. schrieb: > Wie gesagt, dass sind alles IIR Filterlösungen und ich will > herausfinden, ob das ein paar Jahre später nun auch mit FIR Filtern > möglich ist Das ist schon eine ganze Weile möglich, denn das Problem liegt nicht primär an der Rechenzeit: Ich hatte Mitte der 90er ein DSP-System aufgezogen, mit dem ich bereits Frequenzweichen gebaut habe und auch die weiter oben angesprochene Reflektionsunterdrückung realisieren konnte. Das Thema war damals noch recht neu und galt als die schlagkräftigste Waffe in den Tonstudios, um miese Akustik zu bekämpfen. Abgesehen von dem Umstand, dass ich je Kanal einen eigenen DSP gebaucht habe, wegen der Bandbreite gibt es aber zwei "issues": 1) Die Unterdrückung und Raumkorrektur funktioniert bekanntlich nur für einen einzigen Punkt richtig, was noch akzeptabel ist, wenn es um einen Mischplatz geht. Sie ist aber auch stark temperaturabhängig, was die hohen Frequenzen angeht. Es braucht also Kalibrierung. 2) Für die Bässe funktioniert das Prinzip wiederum sehr gut, bis auf den unglücklichen Umstand, dass tiefe Frequenzen einen sehr langen FIR-Filter erfordern, welcher in der klassischen Lösung mit gehörigem pre-ringing daherkommt und allerlei Artefakte veranstaltet, die mehr aus musikalischer Sicht negative Effekte machen, als für den Studiobetrieb abzeptabel sind. Aus dem Grund arbeiten praktisch alle Filter mit IIR im Bassbereich. Richtig ist natürlich, dass man mit der Rechenkapazität heutiger Prozessoren auch IIR-Filter besser berechnen kann, weil deren Qualität mehr oder weniger mit der Abtastfrequenz steigt - siehe die parallel geführte Diskussion über den Linkwitzfilter. Beitrag "Einfacher IIR-Filter für langsamen UC verbessern" Sobald man Filter 2. oder 3. Ordnung verwendet, gehen der theoretische Differentialquotient und der praktisch berechnete Differenzenquotient zunehmend getrennte Wege. Das wird bei den DSPs in SW gerne unterschlagen. Richtig ist daher auch, dass in den SW-plugins die Filter meistens deshalb mit IIR fahren, weil sie Rechenzeit sparen wollen. Von daher schlagen die dort gleich 2 Fliegen mit einer Klappe. Ich würde es derzeit so einschätzen, dass man bei einem aktuellen MINI-DSP-System oder Ähnlichem oberhalb bis etwa 100Hz mit FIR arbeiten sollte. Darunter mit IIR. Bei beiden sind mindestens 96kHz anzusetzen. Zu dem Thema Raumkorrektur werfe ich noch einen Aspekt ein, den ich sowohl hier im Forum, als auch auf DIY und vor allem im Recording-Forum schon vor Jahren detailliert erklärt habe: Zitat: Die Vorstellung, man könne die Raum-Moden im Bassbereich durch einen gegenläufigen IIR-Filter bekämpfen, ist nur näherungsweise richtig. Praktisch sieht es so aus, dass die sich bei Bässen ergebenden Überlagerungen durch Reflektionen aus Teilwellen zusammensetzen, die nur ungefähr einen einschwingenden Verlauf haben. Die Wellen setzen vielmehr sprunghaft ein und haben Transienten. Zieht man davon eine IIR-Welle ab, bleiben diese übrig und erzeugen im Gehör hochfrequente Anteile im Klang. Das hört sich nicht nur komisch an, sondern verändert auch die Lokalisationsfähigkeit- / möglichkeit der Schallquelle. Real kann man dadurch mitunter die Lautsprecher, also die Quelle des Schalls stärker lokalisieren, was eigentlich nicht der Fall sein sollte. Es ist aus meiner Sicht mit den heutigen technischen Möglichkeiten viel besser, die Reflexion der Bässe durch echte Konterechos nachzubilden und die Transienten real mitzunehmen. Diese Technik habe ich schon vor 10 Jahren mit meinem FPGA-DSP-System demonstriert. Es ist ehrlich gesagt auch nicht viel dran, muss man sagen, außer eben dem Umstand, dass ein FPGA mitsamt ausreichendem RAM die Möglichkeit schafft, das sehr einfach hinzubekommen und parallel Echos zu modellieren und durch angepasstes Summieren die sich stufenweise aufbauende Konterwelle zu generieren. Das Problem ist dann, das genau zu vermessen. Siehe auch: Beitrag "Gegenschall-Technik zum kaufen und in Kiste verbauen?" Markus W. schrieb: > 96000 Samples erfordern bei 3400 TAPs und "normaler Konfiguration" eines > symmetrischen FIRs 48000 Additionen für die Spiegelung sowie > anschließend noch 48000x3400 Multiplikationen. Das wären 165 Mio > Operationen. und damit perfekt für einen FPGA, der dafür nur einen Zähler und einen Multiplier braucht. Wie aber oben schon angedeutet, sollte man aber auch hier höhere Abtastraten in Betracht ziehen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.