Hallo, ich würde gerne einen Audiorecorder basteln, der die Daten als Opus oder CELT-Encoded auf eine SDHC-Karte schreibt. Nun würde ich gerne wissen, ob jemand es schon geschafft hat, FFpmeg für AVR zu compilen oder ob es einen anderen Weg gibt, das encoding zu lösen. Und wie viel Rechenleistung bräuchte ein AVR dafür (~14kbps)? Und sehe ich das richtig, dass ein Mikrocontroller das encoding macht und ein zweiter nötig ist, um die Daten auf die Karte zu schreiben? Ansonsten könnte doch wenn die Daten geschrieben werden keine neuen vom Mikrofon empfangen werden, oder?
Nimm sowas: http://www.vlsi.fi/en/products/vs1063.html Je nach verwendetem µC und gewünschtem Dateisystem auf der SD-Karte hat dieser schon genug mit dem Speichern der Daten zu tun.
Carsten schrieb: > Nimm sowas: > http://www.vlsi.fi/en/products/vs1063.html > > Je nach verwendetem µC und gewünschtem Dateisystem auf der SD-Karte hat > dieser schon genug mit dem Speichern der Daten zu tun. Gibt es keinen 32bit µC, der das encoding machen könnte? Decoding von MP3 geht ja anscheinend
Was willst du denn mit FFpmeg? Nimm dir einen STM32F4 (mit FPU, DMA und USB-OTG) z.B. das STM32F4Discovery und mach FLAC Encoding drauf.
Michael schrieb: > Was willst du denn mit FFpmeg? Nimm dir einen STM32F4 (mit FPU, DMA und > USB-OTG) z.B. das STM32F4Discovery und mach FLAC Encoding drauf. FLAC wird aber verdammt schnell verdammt groß
Aah meintest du vielleicht ARM statt AVR? Dann ist es piece of cake. http://wiki.xiph.org/OpusFAQ#On_what_platforms_does_Opus_run.3F Aber ffmpeg brauchste zum encoden gar nicht soweit ich weiß.
>FLAC wird aber verdammt schnell verdammt groß
Mein Gott, nimm einen Laptop mit ner dicken Festplatte.
41kHz Samplerate Stereo und 16Bit pro Sample sind
gerade mal 10MByte pro Minute.
Malte S. schrieb: > Aah meintest du vielleicht ARM statt AVR? Dann ist es piece of cake. > http://wiki.xiph.org/OpusFAQ#On_what_platforms_does_Opus_run.3F > Aber ffmpeg brauchste zum encoden gar nicht soweit ich weiß. Danke für den Link! Um die benötigte Leistung grob schätzen zu können, könnte ich den Opus encoder nur mit RISC-Befehlen compilen, auf meinen Computer laufen lassen und dann auf Real Time runterrechnen, oder ist das zu ungenau? Damit hätte ich eine ungefähre anzahl von MIPS. Aber was ist mit dem RAM? Wie viel brauche ich da? Kann ich das auch auf meinen Computer messen oder gibt es ARM-VMs? holger schrieb: >>FLAC wird aber verdammt schnell verdammt groß > > Mein Gott, nimm einen Laptop mit ner dicken Festplatte. > 41kHz Samplerate Stereo und 16Bit pro Sample sind > gerade mal 10MByte pro Minute. 1. brauche ich nur Mono, also "nur" 5 MBytes/Minute 2. dicke Fetsplatte? SDHC 3. Opus geht ja anscheind auch
Schätze mal im Zweifelsfall kann qemu irgendwas ARMiges emulieren. Wie das genau aussieht und was für ein Core das dann ist keine Ahnung. Ich würde aber mal in der Richtung gucken.
Malte S. schrieb: > Schätze mal im Zweifelsfall kann qemu irgendwas ARMiges emulieren. Wie > das genau aussieht und was für ein Core das dann ist keine Ahnung. Ich > würde aber mal in der Richtung gucken. Danke! Ich hatte BOCHS im Kopf, aber das kann ja leider kein ARM. Was für µC sind denn genereall empfehlenswert? Ich kenne mich da kaum aus. Stromverbrauch ist in diesem Fall relativ wichtig und gcc-support.
Jonathan S. schrieb: > ich würde gerne einen Audiorecorder basteln, der die Daten als Opus oder > CELT-Encoded auf eine SDHC-Karte schreibt Wozu diese Codierungen? Bei unkomprimiertem Stereo-PCM (44.1 kHz, 16 Bit, das ist das CD-Audio-Format) fallen 176.4 kB pro Sekunde an, das sind etwa 635 MB/Stunde. Die kleinste SDHC-Karte ist 4 GB groß, darauf passen also knapp 6.3 Stunden Audiomaterial. Was hast Du vor?
Rufus Τ. Firefly schrieb: > Jonathan S. schrieb: >> ich würde gerne einen Audiorecorder basteln, der die Daten als Opus oder >> CELT-Encoded auf eine SDHC-Karte schreibt > > Wozu diese Codierungen? > > Bei unkomprimiertem Stereo-PCM (44.1 kHz, 16 Bit, das ist das > CD-Audio-Format) fallen 176.4 kB pro Sekunde an, das sind etwa 635 > MB/Stunde. > > Die kleinste SDHC-Karte ist 4 GB groß, darauf passen also knapp 6.3 > Stunden Audiomaterial. > > Was hast Du vor? Ich will in der Lage sein, ein ganzes Wochenende durchgehend aufzunehmen. Man könnte zwar alle 6.3 Stunden die Speicherkarte wechseln, aber das ist unpraktisch. Man könnte aber auch einfach 16GB-SDHC-Karten benutzen, müsste halt nur mit größeren Pointern umgehen können. Zudem werde ich ein eher schlechtes Mikro benutzen, wodurch sich eine Sampling-Rate von 44,1 kHz nicht lohnt. Ich denke, dass 16 kHz @ 16 Bit da angebrachter sind und komme auf 139h. Ist das richtig? Das würde ja locker reichen. Vielleicht könnte man noch eine einfache Kompression darauf anwenden, würde dann allerdings nicht viel bringen. EDIT: Als Datenformat würde ich WAV bevorzugen weil es meines Wissens nach sehr einfach aufgebaut ist (Header + Alle Samples hintereinander). Oder gibt es da was besseres?
Schau Dir mal Mini-Disc Recorder an. Meiner (gefühlte 20 Jahre alt) kann 8 Stunden am Stück aufnehmen und die Aufnahme bei Stille pausieren. Vielleicht reicht das ja schon, wäre jedenfalls relativ preisgünstig und schon fix und fertig. Ansonsten würde ich auch zu einem Computer raten, z.B. ein Netbook.
Schau Dir mal folgende AppNote an: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00204907.pdf Decoding wegwerfen, dafür SD-Card einbauen und fertig ;-)
Stefan Frings schrieb: > Schau Dir mal Mini-Disc Recorder an. Meiner (gefühlte 20 Jahre alt) kann > 8 Stunden am Stück aufnehmen und die Aufnahme bei Stille pausieren. > > Vielleicht reicht das ja schon, wäre jedenfalls relativ preisgünstig und > schon fix und fertig. > > Ansonsten würde ich auch zu einem Computer raten, z.B. ein Netbook. Danke für den Tipp mit silence! Dann könnte man relativ einfach und effektiv RLE drüberlaufen lassen. Gemutet wird, wenn das Signal zu schwach ist (stille) oder die entropie zu hoch ist (rauschen). Notebook ist leider keine Lösung da das Gerät sehr kompakt sein muss. Martin H. schrieb: > Schau Dir mal folgende AppNote an: > http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00204907.pdf > > Decoding wegwerfen, dafür SD-Card einbauen und fertig ;-) Wenn man kein Decondig macht, kann man doch einfach 16000/sekunde den Wert vom ADC nehmen und in die Datei schreiben, oder?
Jonathan S. schrieb: > EDIT: Als Datenformat würde ich WAV bevorzugen Dann aber entfällt doch Deine Eingangsforderung nach "Opus" bzw. "Celt". Wo also ist das Problem? Jonathan S. schrieb: > Man könnte aber auch einfach > 16GB-SDHC-Karten benutzen, müsste halt nur mit größeren Pointern umgehen > können. Muss man auch nicht, denn die maximale Dateigröße ist durch das verwendete Dateisystem (FAT32 laut SDHC-Spezifikation) begrenzt. Du kannst aber völlig problemlos Deine Aufzeichnung in z.B. 1 GB-Häppchen zerlegen. Wenn Du mit 16 kHz Samplerate und 16-Bit-Mono-Samples arbeitest, kommst Du auf 32 kByte/sec, also 115.2 MByte/h. Damit genügt eine 4 GB-Karte schon für 34.7 Stunden, was mehr als ein Tag ist. Deutlich mehr bekommst Du auf die Speicherkarte, wenn Du eine Audiokompression anwendest. Das ist am einfachsten mit einem externen Audiocompressor zu erledigen, wie es sie beispielsweise von VLSI gibt: http://www.vlsi.fi/en/products.html Hier bietet sich der VS1063 an, oder, wenn Du auf Deinen µC auch verzichten kannst, und eine Einchip-Lösung haben möchtest, der VS1005. Klar, die Dinger kosten etwas, aber dafür nehmen sie Dir auch /sehr viel/ Arbeit ab.
Ich habe gesagt decoding wegschmeißen, nicht encoding! Vermutlich lässt sich das aber eh nicht trennen.
Rufus Τ. Firefly schrieb: > Jonathan S. schrieb: >> EDIT: Als Datenformat würde ich WAV bevorzugen > > Dann aber entfällt doch Deine Eingangsforderung nach "Opus" bzw. "Celt". > Da ich mich mit µC kaum auskenne und ich mit 16GB immerhin mindestens 139h Encoding hinbekomme muss mir das erstmal reichen. Rufus Τ. Firefly schrieb: > Jonathan S. schrieb: >> Man könnte aber auch einfach >> 16GB-SDHC-Karten benutzen, müsste halt nur mit größeren Pointern umgehen >> können. > > Muss man auch nicht, denn die maximale Dateigröße ist durch das > verwendete Dateisystem (FAT32 laut SDHC-Spezifikation) begrenzt. Du > kannst aber völlig problemlos Deine Aufzeichnung in z.B. 1 GB-Häppchen > zerlegen. > ExFAT Martin H. schrieb: > Ich habe gesagt decoding wegschmeißen, nicht encoding! > Vermutlich lässt sich das aber eh nicht trennen. Wie gerne ich auch einen Opus Recorder gemacht hätte, ist mir das alles für mein erstes Projekt in diese Richtung zu kompliziert. Da kaufe ich mir lieber größere Karten und mache muting + RLE. Kann mir jemand einen günstigen 32bit-µC empfehlen? Ich finde die ganzen Typen verwirrend. Ist etwas STM32-Artiges gut?
Jonathan S. schrieb: > ExFAT Nicht auf SDHC, das ist erst bei SDXC spezifiziert. Ja, die SD_irgendwas_-Spezifikation schreibt das verwendete Dateisystem vor: SD FAT16 SDHC FAT32 SDXC ExFAT Außerdem: Schon irgendwo mal 'ne ExFAT-Implementation für irgendeinen µC im Quelltext gesehen?
Rufus Τ. Firefly schrieb: > Jonathan S. schrieb: >> ExFAT > > Nicht auf SDHC, das ist erst bei SDXC spezifiziert. > > Ja, die SD_irgendwas_-Spezifikation schreibt das verwendete Dateisystem > vor: > > SD FAT16 > SDHC FAT32 > SDXC ExFAT > > Außerdem: > Schon irgendwo mal 'ne ExFAT-Implementation für irgendeinen µC im > Quelltext gesehen? Ok. Dann SDHC. Hatte eh vor, die Datei alle 15min. oder so zu splitten. Ich stelle mir auch ziemlich unschön vor, eine 16GB-Datei unter Win zu öffnen.
Jonathan S. schrieb: > Wie gerne ich auch einen Opus Recorder gemacht hätte, ist mir das alles > für mein erstes Projekt in diese Richtung zu kompliziert. Da kaufe ich > mir lieber größere Karten und mache muting + RLE. > > Kann mir jemand einen günstigen 32bit-µC empfehlen? Ich finde die ganzen > Typen verwirrend. Ist etwas STM32-Artiges gut? Jetzt mal im ernst: Um was geht es? Willst du was lernen oder musst du ein konkretes Problem lösen? 1) Wenn du ein konkretes Problem (eine ganze WE Audio aufzeichnen) lösen musst, dann würde ich mir folgendes anschauen: http://www.thomann.de/de/portable_recorder.html Wie wichtig ist dir die Aufnahme? Was machst du, wenn deine Selbstbaulösung nach ein paar Stunden Probleme macht? 2) Was lernen: Welche Erfahrung hast du? Schonmal einen uC programmiert? Kannst du C? Traust du dir das zu, an einem STM32F4 einen Codec (AD/DA) Wandler dran zubauen? (ok. für WAV+RLE reicht auch ein AVR) Schaltplan entwerfen + Audio-Vorstufe? Mikrofonvorstufe? Das ganze zu layouten? Layout Fehler zu suchen? Dann die ganze SPI-Programmierung (AD-Wandler, SD-Karte, Filesystem) Evtl. noch ein Display? Mein Vorschlag, wenn du wirklich selbst was programmieren willst, nimm dir ein (fast) fertiges Produkt, das du ändern kannst, z.B. das VS1063 Eval Board. Findest du hier: http://verkkokauppa.planeetta.net/epages/Planeetta.sf/en_GB/?ObjectPath=/Shops/vlsi/Products/VS1063_PROTO_BOARD. Kostet ganze 45,- € Das Board hat schon eine fertige Firmware drauf, die (fast) das macht, was du möchtest. Wenn man sowas als Basis nimmt, hat ein erfahrener Programmierer die Aufgabe in ein paar Stunden erledigt. Wenn du es dir schwerer machen aber auch mehr Freiheiten haben möchtest, kannst du dir bei E-Bay das Open407V-D Kit besorgen, das enthält zumindest funktionierende Hardware für einen STM32F4 inkl. Audio AD/DA Interface, SD-Card und Display. Dann musst du dich nur noch um die Software kümmern. Der STM32F4 hätte genug Power, um MP3 Encoding in Software zu machen.
klausr schrieb: > Jetzt mal im ernst: Um was geht es? Willst du was lernen oder musst du > ein konkretes Problem lösen? Beides. Ich will µC programmieren und da ich keinen passenden Recorder gefunden habe, wollte ich das mal ausprobieren. klausr schrieb: > Wie wichtig ist dir die Aufnahme? Was machst du, wenn deine > Selbstbaulösung nach ein paar Stunden Probleme macht? Das ist nicht so schlimm. klausr schrieb: > Schonmal einen uC programmiert? > Kannst du C? µC habe ich noch nicht programmiert und C musste ich zum Glück auch noch nicht lernen. Da ich allerdings µC und in OpenCL programmieren will werde ich das wohl tun. Ich denke allerdings nicht, das ich da große Schwierigkeiten haben werde. klausr schrieb: > Traust du dir das zu, an einem STM32F4 einen Codec (AD/DA) > Wandler dran zubauen? Wenn ich mich auf WAV + RLE beschränke sollte das schon gehen. Hoffe ich. klausr schrieb: > Schaltplan > entwerfen + Audio-Vorstufe? Mikrofonvorstufe? Ich habe einen selbstgelöteten Mikrofonverstärker hier rumliegen. Den könnte ich mir mal anschauen. klausr schrieb: > Wenn du es dir schwerer machen aber auch mehr Freiheiten haben möchtest, > kannst du dir bei E-Bay das Open407V-D Kit besorgen, das enthält > zumindest funktionierende Hardware für einen STM32F4 inkl. Audio AD/DA > Interface, SD-Card und Display. Dann musst du dich nur noch um die > Software kümmern. Inwieweit muss ich mich da um die SDHC-Card kümmern? Habe da noch keine gute Spec zu gefunden, habe aber auch nicht wirklich gesucht.
Jonathan S. schrieb: > C musste ich zum Glück Jonathan S. schrieb: > C musste ich zum Glück auch noch > nicht lernen. Von wegen Glück. Mit solchen Sprüchen machst du dir in einem uC Forum keine Freunde ;-)
> Jonathan S. schrieb: >> C musste ich zum Glück auch noch >> nicht lernen. > > Von wegen Glück. Mit solchen Sprüchen machst du dir in einem uC Forum > keine Freunde ;-) Seitdem ich gelernt habe, dass in C a[5] das gleiche wie 5[a] ist, finde ich C strange. http://stackoverflow.com/questions/381542/in-c-arrays-why-is-this-true-a5-5a
Ja, die kurioseren Eigenheiten. Wenn du allerdings verstanden hast, warum das so ist, kann dir schonmal eine Menge Böses™ weniger passieren :)
Jonathan S. schrieb: > Ich will in der Lage sein, ein ganzes Wochenende durchgehend > aufzunehmen. Es gibt auch Audiokompression, die wesentlich weniger Rechenleistung fordert. Aber natürlich ist die auch weitaus weniger effizient. Aber vermutlich ist das in deiner Anwendung garnicht nötig. Das hört sich ziemlich nach einer Überwachungsanwendung an. Da wird also sowieso 99% der Zeit nichts als Rauschen und unwichtige leise Umgebungsgeräusche zu hören sein, die kein Schwein interessieren und über die du zur Auswertung mühselig hinwegspulen mußt. Wenn das so ist, dann wäre es viel sinnvoller, noch vor der Aufnahme das Signal zu klassifizieren und nur den Teil aufzuzeichnen, der mit einiger Wahrscheinlichkeit brauchbare Informationen enthält. Das spart viel mehr Speicherkapazität als jede noch so ausgefeilte Kompressionsmethode und das bei sehr viel weniger Rechenzeitaufwand. Der einfachste Trigger wäre natürlich schlicht ein gewisser Mindestpegel. Wenn aber das, was dich konkret interessiert, gewisse charakteristische Signaleigenschaften hat, kann man den Trigger weiter verfeinern. Menschliche Sprache läßt sich z.B. relativ leicht als solche erkennen.
Jonathan S. schrieb: > µC habe ich noch nicht programmiert und C musste ich zum Glück auch noch > nicht lernen. Da ich allerdings µC und in OpenCL programmieren will Wie kommst du darauf, dass du einen µC in OpenCL programmieren kannst? OpenCL ist für massive Parallelarchitekturen aka Grafikkarte gedacht. Nix uC. Das einzige, was ich mir bei dir jetzt noch vorstellen kann, nimm einen AVR, Bascom und den eingebauten AD Wandler (hat zwar nur 10 bit, aber zum aufzeichnen sollte es reichen). Es soll auch irgendwo einen FAT32 SD-Card Treiber für Bascom geben. Wenn das dann läuft, denke über externe AD-Wandlung nach. Falls doch C, mein Tipp: C lernt man nicht am µC - arbeite erst (am besten gleich mit dem gcc auf'm PC) ein gutes C Tutorial durch und besorg dir dann den Kernighan Richi http://de.wikipedia.org/wiki/The_C_Programming_Language Es gibt auch noch andere gute Bücher zum C lernen, habe da aber keinen Überblick, da ich C von >25jahren gelernt habe (damals auf'm Amiga).
Jonathan S. schrieb: > Seitdem ich gelernt habe, dass in C a[5] das gleiche wie 5[a] ist, finde > ich C strange. Eigentlich nicht - wenn man mal Assembler programmiert hat ist einem 5[a] sofort klar: "Damals" auf dem 68k: move.b 5(a0),d0. Eigentlich muss man nur begreifen, dass eine Array-Variable gleichzeitig auch ein Pointer ist.
c-hater schrieb: > Wenn das so ist, dann wäre es viel sinnvoller, noch vor der Aufnahme das > Signal zu klassifizieren und nur den Teil aufzuzeichnen, der mit einiger > Wahrscheinlichkeit brauchbare Informationen enthält. Das spart viel mehr > Speicherkapazität als jede noch so ausgefeilte Kompressionsmethode und > das bei sehr viel weniger Rechenzeitaufwand. > > Der einfachste Trigger wäre natürlich schlicht ein gewisser > Mindestpegel. Wenn aber das, was dich konkret interessiert, gewisse > charakteristische Signaleigenschaften hat, kann man den Trigger weiter > verfeinern. Menschliche Sprache läßt sich z.B. relativ leicht als solche > erkennen. Es geht um Sprache. Hast du Infos darüber, wie das mit wenig Rechenleistung geht? Ich kenne nur, dass das Signal mittels FFT zerlegt wird und bei bestimmten Frequenzen + Oberschwingungen Sprache angenommen wird. klausr schrieb: > Wie kommst du darauf, dass du einen µC in OpenCL programmieren kannst? Hab ich nicht gesagt. klausr schrieb: > Das einzige, was ich mir bei dir jetzt noch vorstellen kann, nimm einen > AVR, Bascom und den eingebauten AD Wandler (hat zwar nur 10 bit, aber > zum aufzeichnen sollte es reichen). Es soll auch irgendwo einen FAT32 > SD-Card Treiber für Bascom geben. Wenn das dann läuft, denke über > externe AD-Wandlung nach. Danke. Wäre wohl das einfachste.
Bei Sprache kommen auch die diversen Telefonie-Codecs in Betracht. Hardware dafür könnte auch in äteren ISDN- oder DECT Geräten von der Schlachtbank zu finden sein.
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.