monitor 1.9.0 - aber richtig :)

[nepomuck]

Noch ein Beitrag zum Kommunikationsprotokoll:
Bei der Channel-Info (Kommando 203) sollte noch ein Bit 2^3 eingefügt werden. Damit man 2^2 für 512Baud POCSAG und 2^3 für 1200 Baud POCSAG nehmen kann.

Übernehme ich in das Protokoll wie vorgeschlagen

Inquiry (Kommando 210,110):
Macht es Sinn die Antworten zu "quittieren" ?

Das ist tatsächlich nicht nötig. Ich ändere Die Dokumentation entsprechend und streiche die Quittung bei den Kommandos, die darauf verzichten können.

Bei den Aufnahmekommando könnte man ggf. bei einer Antwort, daß die Aufnahme schon läuft, bzw. die Aufnahme beendet ist, noch die geplante (gesamte) Aufnahmedauer mitgeben.

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.

(Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

OK. Da liegt wahrscheinlich der Fehler. 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"?

Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht.

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.

Die 320 ist jetzt in 320 geändert

das ändert alles :-)

Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen.

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?
Die Pocsac-Struktur übernehme ich ins Protokoll wie vorgeschlagen.

... würde ich den Dateinamen in der Version 2.0 so lassen ...
Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

Damit können alle gut leben.

Das überarbeitete Protokoll poste ich im Laufe der nächsten Tage,
Grüße,
Andreas

[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