monitor 1.9.0 - aber richtig :)

[Buebchen]

Wäre möglich, aber macht das Sinn? Der Client hat ja die Zeit selbst vorgegeben und erwartet einen "Aufnahme beendet". Er braucht die "Zischenzeit"-Angabe vom Server nicht auszuwerten.

Der Gedanke ist, daß der Client dem User anzeigen kann,wie lange er noch auf die Datei warten muss bis sie fertig ist. Wenn zwei Benutzer eine Aufnahme mit unterschiedlichen Aufnahemdauern auslösen kann sich die anfängliche Aufnahmedauer verändern. Das weiss der erste Client aber dann nicht und versucht die Datei zu öffnen, obwohl sie noch im Zugriff ist.

Ich move das Executable monitord nach erfolgreichem make in ein anderes Verzeichnis, in dem sonst nur die .xml drin steht. Da kann er die Module nicht finden.
Wie heissen die Moduldateien? Kann man einen Failsafe einbauen, so dass monitord eine klingende Fehlermeldung ausgibt wie "Module nicht gefunden"?

Ist schon in Arbeit. Bisher war der Pfad fest auf die SVN Ordner verknüpft, da es auch noch kein Install dazu gibt.

Um Fehler zu vermeiden, sollte monitord.xml dann gar keine Nummern sondern nur Namen deklarieren. Die Nummerierung erledigt monitord dann intern gemäß der Reihenfolge der Kanäle in der Config.

Hmm. Dann müßte ich unter Windows die Kartennummer anders hinterlegen (Windows nutzt primär die Gerätenummer, nicht seinen Namen. Würde aber gehen. Werde ich mal Testweise umbauen.

OK. Dan bekommt der 300 ein Textfeld am Ende. Was machen wir, wenn es keinen Text zu übermitteln gibt? Lassen wir das Feld weg oder sendet der 300 in dem Fall ein einzelnes ":" am Ende?

Ich sende dann ein ":" ohne nachfolgenden Text.

[nepomuck]

Wenn zwei Benutzer eine Aufnahme mit unterschiedlichen Aufnahemdauern auslösen kann sich die anfängliche Aufnahmedauer verändern. Das weiss der erste Client aber dann nicht und versucht die Datei zu öffnen, obwohl sie noch im Zugriff ist.

Hä?
Wenn zwei getrennte Clients ein REC-Kommando absetzen, erstellt der monitord auch zwei getrennte Files. Wenn also Client 1 die Aufzeichnung verlängert, betrifft das nicht die Aufzeichnung von Client 2.
Jeder Client weiss daher, dass die Aufzeichnung nach Ablauf seiner Zeitvorgabe zzgl. Zeit für die Umwandlung von raw nach wav oder mp3 fertig sein muss. Eine Zwischenzeitangabe nützt dem Client nichts, da der monitord die Umwandlungszeit von sox/lame nicht vorhersagen kann. Damit wäre die Zeitangabe auch nur eine bessere Schätzung.

Warum sollte der Client ausserdem versuchen, auf die Datei zuzugreifen, bevor er den passenden 104 erhalten hat? Ich würde im Client eine Eventsteuerung einbauen, die den 104 abwartet und dann die REC-Datei per FTP/NFS/CIFS auf den Client holt.

Ich sende dann ein ":" ohne nachfolgenden Text.

So im Protokoll vermerkt.

viele Grüße,
Andreas

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