PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme mit aloop-Device und LUA-Script



McBo
29.12.2013, 15:17
Hallo die Herren,

über die Feiertage hat man ja immer etwas Zeit,
da habe ich mich mal wieder mit monitord befasst.

Ich bin gerade dabei einen kleinen Alarmierungsserver,
auf ARM-Umgebung aufzusetzen.

Der Server sollte ZVEI-Alarmierungen aufnehmen können,
die Daten in mysql schreiben,
Alarmierungen per Push-Service versenden,
sowie einen geschützten Icecast Stream zur Verfügung stellen.

Das ganze habe ich momentan auf einer i386-Umgebung mit 2 Soundkarten
und dem alten monitor 1.8.1 am Laufen.

Jetzt teste ich mit einem Cubieboard 3 (Cubietruck).
Das Board hat genug Dampf.

Leider bekomme ich den alten Monitor 1.8.1 unter ARM nicht mehr ans Laufen.

Hat das schon jemand geschafft ???

Also neuer Versuch mit monitord auf Cubietruck
und einer USB-Soundkarte "SB1140".


root@debian:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 7/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 2: U0x41e0x30d3 [USB Device 0x41e:0x30d3], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0


Wenn ich in der "monitord.xml" das Device "<device>plughw:2,0</device>"
auswähle, werden ZVEI-Alarmierungen ausgewertet.

Nur die LUA-Scripte wollen nicht funktionieren.
Habe dafür die Standard-Scripte verwendet.

Die Scripte werden beim Start von monitord geladen:



14:12:41.033 INFO: monitord/SocketServer.cpp(82) Successfully loaded LUA filter: /root/src/monitord/socketfilter.lua
14:12:41.037 DEBUG: monitord/SocketServer.cpp(851) SocketManager erstellt
14:12:41.036 INFO: monitord/Monitor.cpp(147) monitord socketserver started
14:12:41.069 INFO: monitord/PluginThread.cpp(182) Successfully loaded LUA filter: /root/src/monitord/pluginfilter.lua
14:12:41.071 INFO: monitord/PluginThread.cpp(390) reading plugin configuration


Bei einer Auswertung kommt dann folgender Fehler:


14:15:31.782 ERROR: monitord/PluginThread.cpp(342) Fehler beim Aufruf lua dispatcher POST script:attempt to call a nil value
14:15:31.783 ERROR: monitord/PluginThread.cpp(349) nicht-numerische Antwort vom lua dispatcher script
14:15:31.783 DEBUG: monitord/PluginThread.cpp(90) plugin processing - size=1


Die Daten werden aber trotzdem in die mysql-Tabelle geschrieben.


Mein 2. Problem ist das aloop-device.

Ich würde den Eingangsstream, von einer Soundkarte, gerne für verschieden Services verwenden.
Also für monitord und Icecast.

Das sollte doch mit aloop gehen.

folgendes funktioniert bisher:


arecord -r 44100 -D hw:2,0 -f S16_LE -t wav >hw:0,0
mplayer -ao alsa:device=hw=2.0 -msgcolor -cache 64 hw:0,0


Ich gebe ein Line-IN-Signal über arecord auf das aloop-device (hw:0,0)
Mit mplayer spiele ich diesen Stream wieder auf den Ausgang von hw:2,0.

Das klappt so ganz gut.
Habe es sogar noch mit einer 2. Ausgabe, auf einer weiteren Soundkarte geschafft.

Wieso funktioniert der monitord mit Device "<device>plughw:0,0</device>"
nicht?
Er startet ohne Fehlermeldungen, wertet aber kein ZVEI aus.
Läuft monitord nicht mit aloop?


Wer kann mir helfen?

Gruß

Marcel

Moo
26.01.2014, 19:14
Habe das selbe Problem mit dem Lua Script. Liegt wohl am Pluginfilterscript, weil ich das Socketfilterscript auskommentiert hab, die Fehlermeldungen allerdings weiter erscheinen. Hast du mittlerweile den Fehler gefunden? Ich probier derweil mal munter weiter.

Mfg

McBo
26.01.2014, 19:27
Nein leider nicht. Hier ist es ja ziemlich ruhig geworden.

Habe zwischenzeitlich auch mal mit monitor-ng gespielt.
Damit konnte ich aber wenig Erfolge erzielen.
Am besten läuft auf einer i386 Maschine, das alte monitor 1.8.1. Auf einer ARM Hardware bekomme ich es aber nicht kompiliert.

Also müssen wir weiter an der Lösung mit den LUA-Scripten basteln.

Auf was für einer Hardware und OS probierst Du gerade?
Ich teste auf einem Raspberry und einem Cubietruck mit Debian Wheezy.

Gruss

Marcel


Sent from my iPhone using Tapatalk

Moo
26.01.2014, 19:31
Auch auf einem Pi mit Raspbian

McBo
26.01.2014, 20:14
Liegt es eventuell an unserem Pi als Hardware?
Ist da irgend etwas beim kompilieren falsch gelaufen?

Scheinbar gibt es bei anderen i386 Linux Usern, keine Probleme.

Ich habe noch zu Testzwecken ein Atom PC mit Debian laufen. Werde hier monitord mit den LUA-Scripten testen.

Mein Ziel ist aber ein Mini-Alaramierungsserver mit SQL DB.
Auf einem Raspberry Pi oder CubieBoard.

Moo
26.01.2014, 20:39
Das könnte durchaus sein.

Hast du es denn hinbekommen z.B. ein Python Script damit aufzurufen?
Weil an sich arbeitet er das PluginfilterScript wohl ab und Daten trägt er ja auch ein.
Notfalls würde ich das dann halt erstmal so weiterlaufen lassen.

McBo
26.01.2014, 22:20
Hi,

so habe getestet.

Läuft auch nicht.
Daten werden ausgewertet und landen in der SQL-Datenbank.

Nur das LUA-script läuft nicht und bringt folgenden Fehler:

<code> 22:10:58.601 ERROR: monitord/PluginThread.cpp(342) Fehler beim Aufruf lua dispatcher POST script:attempt to call a nil value
22:10:58.601 ERROR: monitord/PluginThread.cpp(349) nicht-numerische Antwort vom lua dispatcher script</code>

Den Fehler hatte ich auf dem Raspberry und Cubie auch.

Was ich unbedingt benötige ist das Filtern der Doppel-Alarmierungen in der Datenbank.
Das könnte ich mit SQL-Abfragen hinbekommen, müllt aber die DB zu.

Und die Möglichkeit der Aufnahme von Alarmierungen.
Das geht wohl nur mit Client-Befehlen, die werden aber bei mir absolut ignoriert. :-(

Ich habe schon versucht, mir einen PHP-Socket Client zu bauen, der dann den REC-Part übernimmt.
Dabei scheitere ich aber an dem belegten Sound-Device.
Das müsste also über eine Pipe oder ein Aloop-Device laufen.
Oder über eine 2. Soundkarte, was sehr aufwendig ist.

Da fehlen mir aber die Linux-Kenntnisse.

Gruß

Marcel

Jockel91
19.03.2014, 11:05
Konnte einer von euch das Problem mit der Soundkarte jetzt lösen. Also das auch parallel darauf zugegriffen werden kann?

Danke und Gruß
Jockel