Wenn wir die digitale I2S-Schnittstelle (für das Mikrofon), mit der Arduino Sound library nutzen wollen und WLAN voraussetzen, müssten wir auf Boards mit WLAN und Cortex M0 zurückgreifen. Ich weiß nicht, ob die lib auch mit anderen board tut oder gar mit dem ESP läuft.
Diese boards sollten jedenfalls die lib unterstützen, z.B.:
Ohne WLAN gibt es den Cortex M0 auf diversen boards, im ProMini-form-factor als SparkFun SAMD21 Mini Breakout, mit SD-Interface zur lokalen Aufzeichnung als Arduino MKR ZERO oder Adafruit Feather M0 Adalogger oder mit SD, Solar-Unterstützung und Bee-Socket als SODAQ Autonomo
Danke für den Link, die erwähnte App “Bee Health Guru” habe ich unter Audio Analysing Apps for Mobile Devices aufgenommen.
- für die Lerndaten sollten wir den Idealfall anstreben: 24/7 Messung. Es wird sicher Ausfallzeiten geben, aber die können wir durch die Anzahl der Standorte kompensieren.
- Strom aus der Steckdose und LAN/WLAN - hier wäre meine Minimalanforderung: der betreuende Imkernde geht jede Woche einmal zum Standort, tauscht händisch einen USB-Stick/SD-Karte und überträgt anschließend die Daten vom zu Hause aus. Aber das würde ich nur in machen wollen, wenn wir nicht genug Standorte ran kriegen (<12).
- wir müssen eine verlustfreie Kompression machen, z.B. mit flac FLAC - Free Lossless Audio Codec
- am besten wären 44,1kHz, minimal 32kHz.
- An die Chunks haben wir keine Anforderungen.
Wir würden am Liebsten einen BeagleBone Green nehmen, weil der bei der Audiodatenverarbeitung deutlich besser ist als der Raspi (er kann 4 Kanäle), preislich und in seinen anderen Features aber vergleichbar.
Hallo in die Runde,
Das sehe ich auch so.
Für die 24/7 live/non-live recording/streaming/Bienenstockstethoskop Geschichte würde ich ebenfalls gerne Hardware verwenden, auf der Linux läuft. Weil SD Karten im Freien gammlig sind, sollten wir vielleicht im “non-connected” Fall stinknormale USB-Sticks verwenden, weil hier wenigstens die physikalische Steckverbindung von Haus aus robuster ist? Ein Seitenblick wäre hier auch auf Hardware mit eMMC Schnittstelle möglich, wie es z.B. die Geräte der ODROID Serie bieten.
Ich fände auf jeden Fall toll, auch die Möglichkeiten zu erforschen, die uns Microcontroller in diesem Bereich bieten. Für den allerersten (auch feldeinsatzfähigen) Prototypen würde ich aber definitv erstmal eine Linux-basierte Lösung anstreben - ohne Löten also ;].
arecord wird ja vermutlich definitiv unser Arbeitspferd werden. Hier und hier finden sich schöne Beispiele, wie damit in Kombination mit sox sowie flac verfahren werden sollte, um z.B. in einem Schritt aufzunehmen, zu resamplen und zu enkodieren:
arecord -d4 -f dat -t wav -r 48000 -c 2 | sox - -b16 -r16k -c1 -t wav - | flac - -o message.flac
Habt Ihr das bei Euren ersten Prototypen auch schon so in der Art gemacht?
Siehe auch die ersten Schritte für einen Wrapper um arecord herum für eine reboot-sichere Aufzeichnung von Audiosamples.
Viele Grüße,
Andreas.
Hallo @caro, danke für deine Anmerkungen. Lossless brauchen wir, ja? Hatte ich schon befürchtet, da wir ja bisher nicht genau wissen wonach wir suchen (sagt da die Bienen-Literatur etwas dazu?) Aber insgeheim habe ich doch auf eine höhere Kompression gehofft. Was würde passieren wenn wir verlustbehaftet komprimieren? Welche Frequenzbereiche sind z.B. bei MP3 besonders betroffen?
Kannst du nochmal sagen, was die negativen Erfahrungen beim RasPi waren? Die allgemeine Stabilität, die SD als Speicher? @mhies du hast ja auch einen RasPi im Dauerbetrieb laufen wie schaut es da mit der Stabilität aus? Mein 3er auf dem Schreibtisch hat ab und an auch Aussetzer. Vorteil wie Nachteil des RasPi ist die SD-Karte, damit kann man schnell ein OS klonen, komplette “vorinstallierte” Betriebssysteme (aus)tauschen, das macht aber auch die Hardware fragiler. Müssen wir uns diesen Punkt als Anforderung nochmal genauer ansehen? Warum habt ihr den BeagleBone green genommen und nicht den normalen? Nutzt ihr die grove-Schnittstelle? Je nachdem was die Imker damit machen müssen - WLAN SSID / PW einrichten - könnte ein Monitoranschluss nicht verkehrt sein.
Lasst uns bitte hier nochmal die Anforderungen genauer durchgehen um ein taugliches Board dann auszuwählen.
@einsiedlerkrebs du schreibst unter Research: audio stream with Linkit 7688, dass der LinkIt Smart 7688 “seems to be a bit slow” für was genau? Streaming, Recording? Ist der aus dem Rennen? Die I2S-Schnittstelle fände ich hier für uns attraktiv. @weef kannst du abschätzen welche Board-Liga wir benötigen, wenn wir gleichzeitig aufzeichnen, (verlustfrei) encodieren und verschicken wollen?
Brauchen wir die 4 Audiokanäle, wenn ja für was? Macht es überhaupt Sinn 4 Völker gleichzeitig mit Audio zu monitoren? Bekommen wir die Daten von 4 lossless-Audio-Aufzeichnungen als 24/7 halbwegs robust über die Leitung? Oder brauchen wir sogar mehrere Audio-Messpunkte von ein und demselben Volk um z.B. die optimale Mikrofonposition zu bestimmen?
Den use case mit dem Imker als Datenmuli sollten wir erst mal aussen vor lassen, da fällt in einer Woche ja schon sehr viel an Daten an, besonders wenn wir lossless brauchen. Das muss zwischengespeichert werden und dann auch wieder beim Imker über die Leitung. Besprechen wir, wenn wir zu wenige “optimale” Standorte haben.
Ich gehe eher davon aus, dass wir Standorte mit WLAN haben aber kein Stromkabel, ggf. sollten wir für diesen Fall eher ein backup haben (Solarzelle, Akku) als für die Version ohne Datenanbindung.
Zum Thema Lossless Audio Compression Codecs habe ich einen neuen thread erstellt.
Weil das der China-clone von Seeed ist, der ist billiger! ;)
Ausführliche Antwort folgt.
@clemens Die SD Karte ist schwer zugänglich in meinem Raspi Setup, sehr klein und kein Medium was im Feld getauscht werden sollte, dazu müsste man den RPi runterfahren, ich glaube das meint @caro mit schwierigem Handling. Falls kein Wlan zur Verfügung steht könnte man einen USB Stick in wasserdichter Hülle nehmen, der einfach zugänglich ist und gezogen/gesteckt werden kann. Am RPi könnte man auch mehrere Soundkarte via USB anschliesen oder auch den HDMI Kanal benutzen, der hat auch einen Audio Kanal, ich hab aber bisher nur eine IR Beutenkamera angeschlossen, ohne Mic.
Auf keinen Fall würde ich LinkIt Smart 7688 aus dem Rennen schmeißen, bevor wir nicht das getestet haben. Sobald ich ein i2S-mic hab, könnte ich das mal durchspielen. Wobei wir für eine abschließende Betrachtung natürlich den gesammten usecase im Auge behalten sollten, also auch das verschicken der records.
In meinen Augen hat der LinkIt Smart 7688 auch noch andere Vorzüge dem Rasperry Pi und teilweise auch gegenüber dem BeagleBone Green.
Der LinkIt hat auch einen SD-Kartenslot, allerdings wird davon nicht das Betriebssystem gefahren. Das ist ein großer Vorteil in z.B. feuchter Arbeitsumgebung und um z.B. die SD-Karte mal zu tauschen, für den Imker als Datenmuli
Ein weiteren Vorteil ebenfalls die feuchte Arbeitsumgebung betreffend sehe ich darin, dass das die GPIOs auf männlichen Pins ausgeführt werden. Mit z.B. einen Breakoutboard für die Peripherie könnten wir so ganz ohne Steckverbindungen auskommen. (Auch die 3.3V Power kann über die GPIO’s gespeist werden.)
- Der LinkIt Smart 7688 kann direkt Wifi und hat außerdem einen connector für eine externe Antenne.
- Von der CPU ist der Linkit am schmalbrüstigsten, was womöglich einen autonomen Betrieb (gestützt durch Solarzelle) ermöglicht. → Keine Kabel zum Stand nötig.
Insgesamt sind RPI und BBG mit ziemlichen starken CPUs ausgestattet, ferner haben sie noch GPU’s mit an Board. Ich glaube für Audioaufzeichnung ist eine solche Ausstattung ein unerwünschtes Konsumententum.
Ich würde auch sagen so viel Power (CPU / Strom) wie nötig und so wenig wie möglich. Aufzeichnen, encodieren und Verschicken muss halt parallel passieren, wenn wir einen 24/7-Betrieb wollen, daher meine Frage nach dem Aufzeichnungsvolumen. I2S-Mic bringe ich dir morgen mit, dann können wir mal testen, was möglich ist.
Mit welchem Aufzeichnungsvolumen rechnen wir pro Tag? Wenn ich das gerade richtig recherchiert habe (weitere Beispiele) berechnet sich die Größe einer unkomprimierten Audio-Datei nach
Auflösung x Anzahl der Kanäle x Samplefrequenz x Dauer in Sekunden
z.B.
- 16 bit x 1 Kanal x 44100 Hz x 60 Sek. = 42336000 Bit,
das sind ca. 5 MB / Minute!
– das wären 7,3 GB / Tag und wenn wir ca. 50 % mit flac komprimieren könnten 3,7 GB / Tag
– oder 111 GB im Monat!! - 16 bit x 1 Kanal x 32000 Hz x 60 Sek. = 30720000 Bit
– oder 3,7 GB und mit 50 % Kompression 1,8 GB / Tag
– und immer noch 54 GB im Monat!
Eine ganze Menge, die hier über WLAN bzw. dann weiter mit DSL verschickt werden muss, und das im upstream! Müssen wir hier spezeille Anforderungen an die Internet / DSL-Anschlüsse der Teilnehmenden formulieren? Mit der Handy-Flatrate wirds nicht funktionieren. Ein paar upload-Zeiten für exemplarisch 1 GB bei unterschiedlichen Bandbreiten gibt es unter: https://www.onlinekosten.de/internet/download-upload-geschwindigkeit.html, z.B.
1 GB mit 1.024 Kbit/s: 2 Stunden und 10 Minuten
Mein “normaler” innerstädtischer DSL-Anschluss zeigt gerade ↑ 733 kbit/s an, real sind das eher 500 kbit/s, d.h. die 3,7 GB brauchen so 7 bis 8 Stunden.
Ich wollte das auch genau wissen, nicht nur abschätzen und habe das mit dem von @caro präferierten BeagleBone (hier: Black) exemplarisch probiert. Dieser lief unter Debian 9 mit einem normalen 4.9er kernel (kein RT):
$ uname -a Linux beaglebone 4.9.82-ti-r102 #1 SMP PREEMPT Thu Feb 22 01:16:12 UTC 2018 armv7l GNU/Linux
Zum Verarbeiten hat der BBB dieses genau eine Minute langes Bienengeräusch bekommen. Es wurde stereo in 48 ksps mit 24 bit gesampled und mit Audacity auf -3 dB normalisiert und dann zu mono, 44.1 ksps und 16 bit gerechnet:
$ file 180411-135534-mono.wav 180411-135534-mono.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
Zum Enkodieren zu FLAC wurden flac 1.3.2 sowie alternativ flake 0.11 (flake home, flake vom github oder aus den distro-repos) verwendet. Als einzige explizite Konfigurationsparameter haben beide Programme jeweils -0 bzw. -5 bekommen.
Die vier Einzelergebnisse im Folgenden, output teilweise gekürzt:
flac mit -0 :
$ time flac -0 180411-135534-mono.wav . [...] 180411-135534-mono.wav: wrote 3676145 bytes, ratio=0.694 [...] real 0m0.869s user 0m0.600s sys 0m0.184s
flac mit -5 :
time flac -5 180411-135534-mono.wav . 0.678 [...] 180411-135534-mono.wav: wrote 3594038 bytes, ratio=0.678 [...] real 0m1.853s user 0m1.696s sys 0m0.108s
flake mit -0 :
$ time flake -0 180411-135534-mono.wav Flake: FLAC audio encoder version 0.11 (c) 2006-2007 Justin Ruggles block time: 27ms variable block size: none prediction type: fixed prediction order: 2,2 partition order: 4,4 order method: estimate header padding: 4096 input file: "180411-135534-mono.wav" output file: "180411-135534-mono.flac" Signed 16-bit 44100 Hz mono samples: 2646000 (1m0.000s) block size: 1152 progress: 100% | ratio: 0.716 | bitrate: 505.5 kbps | bytes: 3791139 real 0m0.522s user 0m0.404s sys 0m0.088s
flake mit -5 :
time flake -5 180411-135534-mono.wav Flake: FLAC audio encoder version 0.11 (c) 2006-2007 Justin Ruggles block time: 105ms variable block size: none prediction type: levinson-durbin prediction order: 1,8 partition order: 0,6 order method: estimate header padding: 4096 [...] block size: 4608 progress: 100% | ratio: 0.678 | bitrate: 478.7 kbps | bytes: 3590564 real 0m1.763s user 0m1.496s sys 0m0.116s
Zusammengefaßt:
-
ein BeagleBone kann aus einer Minute raw PCM, 44.1 kSamples pro Sekunde in 16 Bit Auflösung in (grob gerundet) einer halben bis zu zwei Sekunden daraus
flacerzeugen (ein Kanal; bei-0resp.-5; Debian 9 usw.). -
flakeist in beiden Fällen auch hier etwas schneller als das ‘Original’flac. -
der Zeitaufwand wächst, egal, bei welcher flac-Implementation, bei längerem “Nachdenken” des flac-Enkodierers und steht irgendwann in keinem sinnvollen Verhältnis mehr zur erzielbaren Bandbreiten-Einsparung (ok, das war jetzt auch nichts Neues ;) ). Deshalb hier nur
-0und-5und keine höheren Werte. -
die Audio-Quelle “viele Bienen” hat wenig Anteile, welche sich in der time domain komprimieren lassen; viele Bienen brummen halt immer, für den Algo sieht sowas sehr nach Rauschen aus - daher lassen sich keine 2:1-Verhältnisse erreichen wie bei Musik- oder Sprachquellen.
Das ist ein gutes Ergebnis, es bedeutet nämlich, daß für lossless compression á la FLAC genügend Reserve auch auf diesem single core Cortex-A8 zur Verfügung steht. Eher begrenzt die upstream-Bandbreite.
Flac ist zwar bitstreamed, aber es läßt sich nicht ohne Weiteres über auch breitbandiges WAN streamen. Es bringt zwar ein einfaches container-Format mit, aber das ist TCP meist egal ;). Deshalb muß ein streaming über ogg- oder mka-Container angedacht werden. ogg z.B. läßt multi-stream container zu, darin ließen sich dann auch irgendwelche komplett asynchron erfaßen analogen oder I2S-Mikrofone unterbringen. icecast oder darkice wären dafür geeignet zu streamen - vorteilhafterweise als einfache Lösungen wie z.B. das hier:
"Software efficiency halves every 18 months, compensating for Moore’s Law.” - David May’s law
Hervorragend, nach so einem kompakten Schnipsel, der exakt dies tut, hatte ich schon immer mal gesucht. Danke!
… und natürlich erst recht für die ausführlichen Leistungstests! Da Du hier nun schon einen kleinen Teststand aufgebaut hast, würden mich natürlich auch brennend die Ergebnisse auf einem LinkIt Smart 7688 mit 580 MHz MIPS CPU interessieren, den @einsiedlerkrebs und ich ebenfalls weiterhin als Kandidaten dafür im Rennen sehen.
Vielleicht kannst Du das mal vergleichsweise sogar auf Deinem Carambola (auch bei Heise) mit nur 320 MHz MIPS CPU näher unter die Lupe nehmen, falls Du keine ähnliche MIPS Maschine zur Hand hast?
Du meinst Carambola2, das ist aber auch ein MIPS, immerhin aber etwas modernerer (24kc) und mit 400MHz. - Aber der sowie auch der LinkIt als OpenWRT/LEDE-Maschinen haben etwas wenig RAM und ROM, wenn es mit weniger Audio-Kanälen dort überhaupt geht, müßte man an Applikationssoftware noch mehr abspecken resp. neu schreiben…
So oder so wird man wohl wieder bei dem helper gstreamer (ver)enden, auch pulsaudio als layer wird nötig.
Ok, ich nahm an wir kämen mit arecord bzw. sox und flac bzw. flake auch zurande. Die Python Implementierung von BERadio läuft bereits auf dem LinkIt von @einsiedlerkrebs, daher dachte ich, dass wir aus diesen Bestandteilen auch etwas sinnvolles für die kleineren MIPSen hinkriegen bzgl. robuster Audiodatenaufnahme und -telemetrie (wahlweise chunked oder streamed, je nachdem was auf welcher Hardware möglich ist).
Du meinst wir brauchen das Tandem zwingend? Und ist das jeweils erhältlich für die kleineren Maschinen bzw. dort einsetzbar? Gstreamer ist recht hungrig, stimmts? Passt der in den wenigen RAM? Fragen über Fragen… ;]
OK, dann das Ganze auch noch mit einem Carambola2. - Gebaut und installiert wurde ein frischer OpenWRT/LEDE trunk (LEDE SNAPSHOT, r6687-d13c7ac). flac und flake gibts da nicht, sondern man nimmt sich die nötigen gstreamer-libs und -plugins.
# uname -a Linux cara 4.9.91 #0 Fri Apr 13 12:36:43 2018 mips GNU/Linux
Also gleiches file wie beim BeagleBone oben per gstreamer zu flac enkodiert:
# time gst-launch-1.0 filesrc location=/tmp/180411-135534-mono.wav ! wavparse ! audioconvert ! flacenc ! filesink location=180411-135534-mono.flac Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:13.465222015 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 0m 13.75s user 0m 13.25s sys 0m 0.27s #
Der Einfluß des Schreibens der flac-Datei auf SD ist etwa 0.2 s (anstelle filesink location=... dann fakesink).
Zur besseren Vergleichbarkeit noch die gstreamer-chain auf dem BeagleBone:
$ time gst-launch-1.0 filesrc location=/tmp/180411-135534-mono.wav ! wavparse ! audioconvert ! flacenc ! fakesink [...] Execution ended after 0:00:01.873631379 [...] Freeing pipeline ... real 0m2.067s user 0m1.992s sys 0m0.060s $
Also kein Unterschied zu den Ergebnissen des BeagleBone von oben, bzw. nur sehr kleiner overhead durch die per shell frei gebaute chain.
Angenommen wir zeichnen mono und auch mit der finalen Samplingrate und -tiefe auf. Schaffen wir es dann gleichzeitig den neuen chunk zu encoded und den letzten chunk zu verschicken? Brauchen wir die SD als Zwischenlager bzw. wie groß / klein müssen oder dürfen sie chunks sein, dass so was (ggf. auch ohne Sd geht?
Wow, vielen Dank für die ausführliche Doku der Tests. Thorstens Wunsch wäre eine Ambisonic-aufzeichnung mit einem Soundfield-Mikrofon, also 4 Mikros in einem Volk, nicht 4 Völker über den selben Pi/BBG/teensy, hier liegt ein Missverständnis vor.
Das damit produzierte Datenvolumen ist eine Herausforderung…2,6TB pro Jahr pro Volk. Für Phase 1 schlage ich vor, max. 20 Völker damit auszurüsten.