Forum: Digitale Signalverarbeitung / DSP Welches DSP für 7.1 FIR-Filter


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Simon F. (snape6666)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Gretel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gretel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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...

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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?!

von Tippgeber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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^^

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hört sich gut an (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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?
Ebay-Artikel Nr. 253942341747

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.

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
Alternativ dazu:
Ebay-Artikel Nr. 123962902103

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

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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 =)

von Rolf S. (audiorolf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Simon schrieb:
> Seit
> Februar kann man oer xilinx IP wohl auch 8 kanal audio von hdmi trennen
> :)

Was kost' der denn?

Gruss
WK

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das richtig sehe ist das beim webpack dabei. Gibt zumindest 
auch ein zwei Beispiele für das Arty Board.

von Videomann (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joa, das Board ist gerade im Zulauf, dann wird getestet. Nächste Updates 
dann wenn das Board da sind :)

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast du dazu vll ein Beispielprojekt an dem ich mich orientieren kann? 
:)

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 -.-

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mimas Artix 7 heist das Board welches das IO unterstüzt... Werde 
berichten wenn es da ist!

von M. W. (elektrowagi78) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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^^

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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".

von Simon F. (snape6666)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Dergute W. (derguteweka)


Bewertung
1 lesenswert
nicht lesenswert
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

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Simon F. (snape6666)


Bewertung
1 lesenswert
nicht lesenswert

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hermann K. (r2d2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Simon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
I see... Naja ich habe mir mal einen Splitter bestellt, dann kann ich 
ich beides testen und sehn was passiert :)

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ergebnisse?

von Christoph Z. (christophz)


Bewertung
1 lesenswert
nicht lesenswert
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...

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.