monitor 1.9.0 - aber richtig :)

[Buebchen]

Mit dem 104:0 Status macht natürlich Sinn. Erst ab dann ist die Aufnahme verfügbar. Jetzt aber zum Haken an der Sache. Pro Kanal wird im Moment nur eine Aufnahme laufen. Diese wird mit einem 104:2: Kommando nach Angabe des letzten Clients verlängert. Das teilt monitord dann auch per 104:2 Kommando allen zur Zeit aufnehmenden Clients mit.

Dann habe ich den Parameter 104:2 falsch interpretiert. Werde mal sehen, ob sich das auch mit einzelnen Aufnahmen realisieren läßt.

[nepomuck]

Das teilt monitord dann auch per 104:2 Kommando allen zur Zeit aufnehmenden Clients mit.

Es macht wenig Sinn, wenn ein Client erfährt, dass ein anderer was aufnimmt. Im Zweifelsfalle geht den Client der betreffende Kanal nicht einmal etwas an. In kommenden Versionen könnte (sollte) es auch eine User-Policy per Kanal geben, so dass nicht jeder Benutzer auch jeden verfügbaren Kanal abhören und auswerten darf.

Ich dachte, der monitord reicht kontinuierlich Datenblöcke von der Soundkarte durch einen Puffer, so dass sich mehrere REC-Tasks simultan daraus bedienen und daher völlig unabhängig voneinander aufnehmen können. Schliesslich greifen ja auch mehrere Auswerter simultan auf den Datenbestand zu.

viele Grüße,
Andreas

[Buebchen]

Es macht wenig Sinn, wenn ein Client erfährt, dass ein anderer was aufnimmt. Im Zweifelsfalle geht den Client der betreffende Kanal nicht einmal etwas an. In kommenden Versionen könnte (sollte) es auch eine User-Policy per Kanal geben, so dass nicht jeder Benutzer auch jeden verfügbaren Kanal abhören und auswerten darf.

Ich dachte, der monitord reicht kontinuierlich Datenblöcke von der Soundkarte durch einen Puffer, so dass sich mehrere REC-Tasks simultan daraus bedienen und daher völlig unabhängig voneinander aufnehmen können. Schliesslich greifen ja auch mehrere Auswerter simultan auf den Datenbestand zu.

viele Grüße,
Andreas

Es ist schon so, daß pro Kanal aufgezeichnet wird (also Mono). Auch getrennte Kanäle in Unterschiedliche Dateien. Pro Kanal ist zur Zeit aber immer nur exakt eine Aufnahme aktiv. Der Hintergrund ist einfach der, daß sonst noch massiver Multitasking nötig wird.

Wenn also ein Client A den Kanal 3 aufzeichnet hat das nichts damit zu tun (und er wird darüber auch nicht in Kenntnis gesetzt) wenn ein Client B den Kanal 1 aufzeichnet.

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.

Disk I/O ist relativ langsam. Ich wollte das nicht zu weit ausbreiten. Einige wollen den monitord auf leistungsschwachen Maschinen einsetzen. Grundsätzlich könnte ich aber sicherlich auch mehrere Dateien innerhalb eines Kanals aufzeichnen. Muss ich aber schreiben. Da Weihnachten naht ist meine Zeit etwas knapp ...

Strukturell gibt es nicht pro Auswerter einen Thread - Nur pro Karte. Die Daten werden nacheinander an die Auswerter vergeben. Danach gehen die Daten dann an die AudioPlugins. Aber alles von einem Thread aus bedient. Ja, ich weiss. Man könnte da ganz toll was mit ThreadPools und WorkerThreads machen ... Wäre was für die Version 2.2 oder so :-)

[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