System für kontinuierliche Audio-Aufzeichnung (BOB Projekt, Phase 1)

bob
audio

#21

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


Developing Saraswati: Getting started with GStreamer
#22

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.


#23

Angenommen wird 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?


#24

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.


DIY Ambisonic Aufzeichnung
#25

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?


split this topic #26

5 posts were merged into an existing topic: DIY Ambisonic Aufzeichnung


#27

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.


#32

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


#33

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.


#34

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?


#35

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.


#36

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.


#37

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


#38

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


#39

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.


#40

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.


#41

Hier nehmen sie Kapton-Tape für festen Sitz der SD am RasPi 1:

raspi1-sd-kapton

(aus Think Different Challenge - The Apple PIIe - Part 4 (yt))


split this topic #43

11 posts were merged into an existing topic: Audio hardware for BeagleBone


#44

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?

https://beagleboard.org/e14-bbbi


#46

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: