Audiorecorder

Jonathan S. schrieb:
> FFpmeg für AVR zu compilen

Ich würde eher einen Z80 nehmen.

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

Decoden ist ja auch vergleichsweise trivial.

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ß.

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.

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 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 :)

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.