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:
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
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 flac erzeugen (ein Kanal; bei -0 resp. -5; Debian 9 usw.).
flake ist 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 -0 und -5 und 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).
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.
Lasst uns erst mal das Standardprogramm abarbeiten, dann schauen wir, was sonst noch geht. Wie gesagt wäre es nett, wenn @caro oder @tox noch etwas zum Raspi-Setup schreiben könnten: Was war hier bisher problematisch, was habt ihr an Software verwendet, Encodierungsparameter, Übertragung? Was ist der Hintergrund für die 4-Kanal-Aufzeichnung? Optimierung der Mikro-Position?
Jedenfalls die schiere Rechenleistung eines BeagleBone betreffend, ganz klar ja.
Nein. Die diente in den Beispielen nur als ‘Lager’ einer vorher erzeugten und für alle Tests identischen Audioquelle. Wenn die Karte nötig wäre, könnte man sie nach kurzer Zeit nicht mehr benutzen.
Das ist stark vom realisierbaren bzw. noch zu vertretenden Ressourcenverbrauch abhängig, v.a. RAM und Interrupt-Last.
Zwei Beispiele mit gstreamer zur Demonstration, daß die SD-Karte oben nur für die Vergleichbarkeit diente:
Im folgenden eine gstreamer-Zeile, die per ALSA den Input einer externen 2-kanaligen Audiokarte zu flac kodiert, wieder auspackt, dekodiert und auf dem Audio-out per default pulse-Senke ausgibt (ein I2S-Mikro würde z.B. auch im ALSA repräsentiert werden):
Obwohl zur Demo funktionierend, ist das im WAN unpraktisch; man wird die Audio-payload (1…n Kanäle) eher in einen ogg-Container legen, welcher mit RTP (sowie RTSP resp. RTCP) gestreamed wird. Und um sich zusätzlichen Streß mit firewalls, Endkunden-Routern usw. zu ersparen, will man vielleicht RTSP über HTTP tunneln. - Das alles ist für ‘near real-time’, sobald die upload-Bandbreite der WAN-Verbindung kleiner ist als die erfaßte Audiomenge, muß ggf. doch wieder eine SD o.ä. als Zwischenspeicher verwendet werden - wenn dieser Buffer nicht im RAM angelegt werden soll/kann. Auch muß man nicht zwingend an streaming denken, wenn das System Massenspeicher hat und chunks zunächst als files ablegen soll - dann kann eine chain aus arecord, sox usw. sinnvoller sein (oben beschrieben von @Andreas, u.a. realisiert von @mhies). OSBH hat dafür ein sinnvolles naming scheme gebaut.
Zwingend nicht, also nein. Das Schöne ist halt, daß man gstreamer sowohl aus Programmen heraus ansprechen kann, oder sich halt (fast) alles auch per gst-launch im cli zusammenkleben kann und dabei sehr einfach zwischen statischen und dynamischen Anforderungen (und derartigen Testquellen und -senken) “umschalten” kann.
Klar; man kann sich das schon bei OpenWRT/LEDE wirklich sehr feingranuliert auswählen, was vom gstreamer-Universum installiert werden soll.
(BTW, OpenWRT/LEDE hat im trunk resp. master inzwischen auch den BeagleBone als target, damit steht für diese Plattform eine weitere sinnvolle Linux-Distro bereit (und @einsiedlerkrebs und ich kennen den maintainer dort für dieses target persönlich ;) ) )
Nicht notwendigerweise, man muß ja nur das installieren und nutzen, das auch gebraucht wird. Hier z.B. kann alles im Zusammenhang mit Video weggelassen werden, dann ist schon der statische, aber v.a. der dynamische Ressourcenverbrauch auch auf ‘kleinen’ Boards komplett vertretbar.
Ja. :) - Für die Beispiele waren nur eine kleine Auswahl aus “base” und “good”, keine “bad”- oder “ugly”-Plugins notwendig (ja, schlimm, - so heißt das dort) , neben gst-alsa und -pulse.
Zu Argumenten, warum ein BeagleBone im Feld einem RasPi überlegen sein kann (in Richtung @clemens, Du fragtest mich, aber ich kann natürlich nicht nicht für @caro und @tox sprechen): sobald der Pi die Werkbank verläßt und “draußen” sein Dienst tun soll, nervt regelmäßg die Kontaktierung der SD-Karte, die beim RasPi ja nicht optional ist, sondern das OS beherbergen muß. Auch wenn man einen Schutzgrad IP65 realisiert bekommen sollte, ist das noch keine Garantie dafür, daß die SD-Kontaktierung sicher durchhält. Außerdem kann die appliance auch herunterfallen, man erkennt von außen nicht, daß die Karte an minimal anderer Position ist, und der Fehler nimmt seinen Lauf… Außerdem erlebt man, daß die Leute irgendwann (oder gleich von Anfang an) der Versuchung erliegen, eben doch Nutzdaten exzessiv auf die SD zu speichern und somit die begrenzten wertvollen v.a. Schreibzyklen ihres Betriebssystem-Speichers verschwenden. Die Wahrscheinlichkeit, daß das System dann deshalb irgendwann nicht mehr richtig funktioniert, steigt dadurch immens.
Bei BeagleBone speichert man das OS auf einer eMMC (wie beim von @Andreas erwähnten Odroid), dort kann man die SD zum Ausprobieren von Systemen sowie z.B. zu deren Vervielfältigung nehmen - aber sie ist eben nicht beim Betrieb erforderlich.
danke für Deine sehr schöne Antwort und den Blick unter die Haube von Gstreamer & Co. Das hört sich vielversprechend an.
Bzgl. des Massenspeichers zum Abpuffern von Nutzdaten: Ich würde einfach mal als gemeinsamen Nenner herausdestillieren: SD Karten stinken, also sollte es mindestens eine SSD oder vergleichbare Disk oder halt eine klassische Spindledisk sein, die dann am universellsten per USB angeschlossen wird, ja?
Die Hardware selbst (ob RaspberryPi, Odroid oder Carambola) ist also relativ egal. In diesem Sinne wäre eMMC u.U. schön, muss aber nicht unbedingt sein.
Sehe ich diese Punkte richtig?
Viele Grüße,
Andreas.
P.S.: Western Digital hat vor ein zwei Jahren eine auf den RaspberryPi zugeschnittene Marketingkampagne für ihre PiDrive Serie gestartet, die mit “low-power consumption” beworben wird. Die könnte man erwägen, wenn man nicht vorhat, sie im Betrieb fallenzulassen (spindle disk). Oder man greift zu einer Premiumgerätschaft (z.B. Samsung 850 PRO), wobei das vermutlich overkill wäre. Oder halt irgendetwas preisgünstigeres mit V-NAND unterhalb dieser Klasse.
The WD PiDrive Node Zero is a compact, all-in-one unit that includes a WD PiDrive connected to a Raspberry Pi Zero through a custom adapter board with 2 USB ports. This unit offers an affordable, low-power storage node with on-board compute capabilities. Ideal for video recording, data logging, offline analytics, and applications where stand-alone operation are needed because of network limitations or privacy/security restrictions.
Also ich betreibe 3 RPis in einer IP65 Box aus dem Baumarkt (Stromverteilerbox für 5-8 €) jeweils unter der Beute, einen seit 3 Jahren, den zweiten und dritten seit einem Jahr ohne Probleme.
