monitor 1.9.0 - aber richtig :)

[nepomuck]

Kommt aber nun Client C und will den Kanal 3 aufzeichnen erhält er den gleichen Dateinamen wir Client A. Die Aufnahme wird ggf. entsprechend verlängert, wenn A's Aufnahme zu kurz wäre. Dann erhalten beide die Info 104:2 und auch 104:0. Das meinte ich mit alle. Nicht unbeteiligte Clients.

Kapiert!
Das kann aber dazu führen, dass ein Client zur Not Minuten oder gar Stundenlang auf seine Aufzeichnung warten muss und dann ein Monster-File erhält.
(Der Kyrill-Tag war ein solcher Extremfall, da ging alle paar Minuten ein Alarm raus)

Vorschlag:
Wir belassen es bei einem Thread pro Kanal für die Aufzeichnung. Der Segmentiert dafür die Aufzeichnung in Blöcke (pro 10 Sekunden ein RAW-File). Vor der Auslieferung an den Client übergibt monitord die Liste der Blöcke an sox, das daraus ein .wav- oder .mp3-File zusammenbaut.
Will ein weiterer Client während einer laufenden Aufzeichnung REC auslösen, läuft der Aufzeichnungs-Thread einfach weiter, monitord merkt sich die Nummern der RAW-Blöcke und denkt sich schon mal einen neuen Namen für den anderen Client aus..
Damit erzeugen wir eine Art pseude Multithread-Aufzeichnung ohne dabei aber die Systemlast zu steigern.
Theoretisch können dutzende verschiedener Clients simultan aufzeichnen so dass jeder seine eigene Datei erhält aber nur ein REC-Thread pro Kanal läuft.

Läßt sich das ohne große Probleme im Code umsetzen?

viele Grüße,
Andreas

[Buebchen]

Will ein weiterer Client während einer laufenden Aufzeichnung REC auslösen, läuft der Aufzeichnungs-Thread einfach weiter, monitord merkt sich die Nummern der RAW-Blöcke und denkt sich schon mal einen neuen Namen für den anderen Client aus..
Damit erzeugen wir eine Art pseude Multithread-Aufzeichnung ohne dabei aber die Systemlast zu steigern.
Theoretisch können dutzende verschiedener Clients simultan aufzeichnen so dass jeder seine eigene Datei erhält aber nur ein REC-Thread pro Kanal läuft.

Läßt sich das ohne große Probleme im Code umsetzen?

viele Grüße,
Andreas

Ööööh ... Nö :-)

Ich denke, ich werde pro REC Modul eine Liste von Dateien pflegen, die parallel geschrieben werden. Dann braucht der Datenblock nur einmal aufbereitet zu werden und wird dann in die einzelnen Dateien geschrieben. Muss nur angepasst werden, daß Client und Datei nicht verwechselt werden :-)

Ich habe nur Sorge, daß die Bearbeitungszeit für einen Datenblock länger ist, als es dauert der nächste Datenblock von der Soundkarte kommt. Dann müßte ich doch noch eine Queue für die Datenpakete machen. Sonst gehen Daten verloren und die Auswerter und/oder Datei bekommt unvollständige Tondaten (Nicht umsonst hat FMS32 diesen Soundkartenreset drin. Ich vermute, genau wegen solcher Probleme)

[Edit]:
Funktion ist jetzt geändert. In der nächsten Version sollte man das nochmal überarbeiten. Nicht alles so richtig hübsch. Aber egal. Die Funktion macht bei ersten Test zumindest keinen Absturz.

Die Dateinamen sehen jetzt so aus:
{Datum-Uhrzeit}_{Kanalnummer}_{jobID}.raw

Bsp:
20071217230000_0_2.raw

Alles ganz frisch. Bei mir klappt es soweit schon. Wer mag kann ja mal rev.230 austesten. Der Pfad zum Plugin kann jetzt auch im monitord.xml definiert werden. Siehe Datei im SVN.

[Buebchen]

Hat jemand mehr als eine Soundkarte ? Insbesonder unter Windows würde es mich interessieren , ob das in der Auswertung fehlerfrei läuft. Die SocketThreads kriegen davon noch nicht so viel mit, der Client dementsprechend auch noch nicht.

Windows interpretiert die Device Defintion von Linux in der monitord.xml nun als Gerätenummer. Also

/dev/dsp0 = Erste Soundkarte
/dev/dsp1 = Zweite Soundkarte
/dev/dsp2 = Dritte Soundkarte
/dev/dsp3 = Vierte Soundkarte

Ich habe ausserdem noch einen Support für lame implementiert. Damit kann man direkt in mp3 aufzeichnen. Das geht zwar, ist aber etwas kniffelig zu installieren. Das muss ich mal in einer ruhigen Minuten dokumentieren, bzw. mal als Beispiel darstellen.

Zumindest die configure Option gibt es schon. Muss mich aber mal mit autoconf befassen, wie nun automatisch den Pfad zu den DLLs, bzw. .so's finde (oder deren Existenz abklären kann).

[Edit]
Nachtrag: rev. 233 im SVN ist gemeint.

[nepomuck]

Nachtrag: rev. 233 im SVN ist gemeint.

Upgedated; make clean; chmod +x config*; ./configure --enable-plugins; make

passiert folgendes:

...
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'virtual void MonitorAudioPlugInRecorder::ProcessAudio(float*, int)':
monitord/plugins/libmplugin_audiorecorder.cpp:211: warning: comparison between signed and unsigned integer expressions
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'void MonitorAudioPlugInRecorder::StartRecording(int, std::string, int)':
monitord/plugins/libmplugin_audiorecorder.cpp:275: error: cast from 'MonitorAudioPlugInRecorder*' to 'int' loses precision
monitord/plugins/libmplugin_audiorecorder.cpp:293: warning: converting to non-pointer type 'long int' from NULL
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'virtual std::string MonitorAudioPlugInRecorder::DoCommand(std::string, SocketThread*)':
monitord/plugins/libmplugin_audiorecorder.cpp:354: warning: comparison between signed and unsigned integer expressions
monitord/plugins/libmplugin_audiorecorder.cpp:359: warning: converting to non-pointer type 'long int' from NULL
make[1]: *** [monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-libmplugin_audiorecorder.lo] Fehler 1
make[1]: Verlasse Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
make: *** [all] Fehler 2

2. Versuch ohne Plugins:
make clean; ./configure; make

make  all-am
make[1]: Betrete Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
g++ -DHAVE_CONFIG_H -I.  -Ijthread-1.2.1/src -D_DEBUG -Wall -pedantic        -g -O2 -MT monitord/monitord_monitord-Monitor.o -MD -MP -MF monitord/.deps/monitord_monitord-Monitor.Tpo -c -o monitord/monitord_monitord-Monitor.o `test -f 'monitord/Monitor.cpp' || echo './'`monitord/Monitor.cpp
monitord/Monitor.cpp: In member function »void Monitor::InitSndCard()«:
monitord/Monitor.cpp:203: Fehler: »class CSndPipe« hat kein Element namens »loadPlugins«
make[1]: *** [monitord/monitord_monitord-Monitor.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
make: *** [all] Fehler 2

Plattform: Athlon X2 mit Ubuntu 7.10 64-Bit.

any Ideas ?

Andreas

[Buebchen]

Hmm. Im oberen build sehe ich nur warnings. Die sind soweit auch ok.

Den Fehler im untern Build habe ich vermutlich schon behoben. Fehlte ein #define.
-> Rev.234 (#define in Monitor.cpp)
-> Rev.235 (#define in CSndPipe.cpp)

Den oberen Teil schau ich mir noch mal an.

[Edit]
Ah. War Blind. Habe den error jetzt gesehen. Schau mich mir an.
[Edit2]
Fehler im ersten Build liegt vermutlich am 64Bit System. Die Zeile kann ich aber bedenkenlos streichen, da sie nur für die ersten Debug Aufnahmen wichtig war.

-> Rev. 236 (pointer cast nach int geht unter 64Bit nicht)

[nepomuck]

Rev. 236

Läuft mit Plugin.
Anmerkung:

104:0:1:rec/20071220001130_0_0.raw

Soll 104 den Dateinamen mit oder ohne Pfad zurückliefern?
Eigentlich ist der Dateiname ein Textfeld und somit in HEX zu codieren.

Edit!
Noch ein großes Problem:
Wenn ich über den Client (telnet localhost 9333) ein paar verschachtelte 204 absetze, bleibt der Client hängen. Die Debug-Anzeige des monitord zeigt an, dass der weiter auswertet, aber beim Client kommt nichts mehr an. Der monitord nimmt auch über die Client-Sitzung keine Kommandos mehr an.
Den 104 übermittelt er aber und dann kann es sein, dass alles wieder geht, oder das nichts geht oder dass Kommandos wie 299 angemommen werden aber die Alarmierungen nicht durchkommen.

viele Grüße,
Andreas

[Buebchen]

Hex kommt. Die Verschachtelung wird tatsächlich noch nicht laufen. Da ist das alte Konzept noch nicht umgestellt (Alle Clients machen nur eine Aufnahme).