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?
1 Like
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):
-
gst-launch-1.0 alsasrc device=hw:1 ! flacenc quality=0 blocksize=200 ! flacparse ! flacdec ! pulsesink
Hier zweigeteilt: Sender nimmt per ALSA auf, kodiert in FLAC und stellt das an einem TCP socket bereit:
-
gst-launch-1.0 alsasrc device=hw:1 ! flacenc quality=0 blocksize=2000 ! tcpclientsink host=localhost port=5002
Empfänger holt payload am socket ab, dekodiert und gibt akustisch per ALSA-Senke aus:
-
gst-launch-1.0 tcpserversrc host=localhost port=5002 ! flacparse ! flacdec ! alsasink sync=false
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.
1 Like
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.
1 Like
Hey @weef,
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.
Grundsätzlich finde ich das WD PiDrive Node Zero Gerät nicht uninteressant:
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.
… eigentlich wie für uns gemacht, nicht?
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.
1 Like
Noch ein Vorschlag von @wilhe_jo in einem anderen thread dazu:
I would stream the recordings to an spi flash and copy the contents to the rpi when it wakes up.
Hi!
IMHO die vernünftigste Variante wäre ein Samplen mit einem halbwegs low-power device und dann z.b stündlich die angefallenen Daten durch ogg,flac oder mp3 auf einer leistungsfähigeren hardware in eine vernünftige Größe zu bringen.
Bei 96ksps und 24bit wären das dann schon 1gb pro Stunde und Kanal… Das ist schon sportlich… 8ksps bei 8bit ergäben ca 30mb pro Stunde…Ob das aber reicht kann ich schwer sagen…
Die 30mb würde ich auf einem spi flash lagern… Gigabytes eher auf SD… SD hat wiederum eigene Probleme (spec nur mit nda,…)…
Beaglebone, rpi,… Haben leider alle kein vernünftiges Powermanagement (verglichen mit einem handy)… Also entweder zumindest solar Panels oder extern Samplen.
73
…aber Du bist auch Profi, da gilt das nicht - es wird geradezu erwartet! :)
Mein Punkt ist nicht, daß es nicht überhaupt gehen würde. Es braucht halt wie immer bedachtsamen und bewußten Umgang mit der Materie der Begierde. Daher umso besser, daß mit Deiner Installation erprobte Dinge in diesem Umfeld existieren - und das trotz und durch Einsatz von einfachen Lösungen.
Als (hobby-)Mitbetreiber eines (hobby-)hackerspace erlebe ich verschiedenste Dinge, welche sich Leute ausdenken, die vorher mit derartiger Technik wenig oder nichts zu tun hatten, und die bisweilen leider wenig bis kein Verständnis dafür aufbringen können, daß sie, wenn sie dann mit irgendeiner NoName-SD vom Drogerie-Discounter diese ihrem RasPi im stolz selber 3D-gedruckten ‘Gehäuse’ spendieren, dann irgendwann aus für sie unerklärlichen Gründen Schiffbruch erleiden (von solchen ‘Kunden’ kann bestimmt auch @simon ein Lied singen ;) ) . Das erstreckt sich nicht nur auf Künstler, bei denen das noch leichter vorstellbar ist… Genau wie bei einer SIM-Karte ist die Art der Kontaktierung einer SD-Karte fehleranfällig für typische derartige Fehler.
Ich breite das deshalb hier so aus, weil es auch bei hiverize eben genau dazu schon gekommen war, nämlich zu Kontaktproblemen der SD-Karten. - Deshalb halte ich die Hinwendung zu eMMC (mindestens für die System"laufwerke") für dieses Projekt für folgerichtig.
1 Like
Hey,
vielleicht bin ich ein bisschen spät :)
hier ist noch ein wissenschaftlicher Artikel in dem auch Bienenschwärme mit Hilfe von Audio aufzeichnungen überwacht werden. Ich denke, dass die Hardware die sie benutzt haben nicht wirklich relevant ist für uns da der Artikel 2009 veröffentlicht ist. Aber es wird auch besprochen welche Frequenzen, man samplen sollte. Im allgemeinen kann man mit Frequenzen zwischen 10 und 1000 Hz rechnen. Man sollte also bei der Microphonewahl darauf achten, dass auch die niedrigen Frequenzen aufgezeichnet werdenn können. Da das menschliche abolute Minimum bei 20 Hz liegt kann ich mir vorstellen, dass einige Microphone auch oft nicht niedriger Frequenzen aufzeichenen können.
2 Likes
Zur Thematik “SD-Karte im Raspberry” sei noch angemerkt: Zumindest der neuste Raspberry Pi 3B+ kann auch von USB-Sticks booten. So ließen sich auch “wetterfest” zwei USB-Ports an nen Außengehäuse führen, um die Wartbarkeit verträglicher zu gestalten: 1x für das Betriebssystem und ggf. 1x für Daten.
2 Likes
Hier nehmen sie Kapton-Tape für festen Sitz der SD am RasPi 1:
(aus Think Different Challenge - The Apple PIIe - Part 4 (yt))
2 Likes
Kleiner Zwischenstand
Da der (freie) WLAN-Treiber des aktuellen OpenWRT mit dem (properitären) WLAN des LinkIt nicht gescheit läuft ist der LinkIt gerade keine Alternative für uns.
Die SD-Karte des RasPis ist im Ausseneinsatz und mit ganzjährlichen Temperaturschwankungen eher negativ aufgefallen, daher ist ein RasPi gerade ebenfalls nicht erste Wahl.
Da @caro schon gute Erfahrungen mit dem BeagleBone gemacht hat und auch @weef den für ein anständiges board für unsere Zwecke hält wäre dieser nun im Rennen. @weef, du sagtest auch, dass es den in “industrial grade” gäbe. Welchen würdest du empfehlen? Ist es der von element14?
Wenn ich es richtig sehe, ist der BeagleBone Black Wireless für uns nicht geeignet, da er zwar WLAN hat, dafür aber Ethernet geopfert wurde.
Die industrial version bei farnell hört sich doch gut an, und wenn WLAN gebraucht wird ein USB-Dongle?
Hier gibt es einen Vergleich von BB Black, Green und Green Wireless:
Noch ein paar Überlegungen zur Datenübertragung:
Die Anforderung an unsere Audiostandorte, dass sie LAN mit guter Uploadgeschwindigkeit haben, ist ja eine recht große Einschränkung.
Es gibt gerade von 02 einen Tarif, bei dem man (bis zu) 10 Simkarten zur LTE Datennutzung für 80 E/m bekommt. Das LTE Cape für den Beaglebone kostet 60Euro (69USD). Wären also gut 250E extra pro Sensorkit. Lohnt sich das? Oder schaffen wir es auch anders?
Gruß caro