monitor 1.9.0 - aber richtig :)

[nepomuck]

Mal eine kurze Zusammenfassung:

Der neue Monitor arbeitet mit einem Backend "monirotd", das zwei Soundkanäle eines Devices dekodiert und die Ergebnisse auf einem TCP-Port für Frondend-Anwendungen ausgibt. Das Protokoll wird dabei den Dienst (FMS, ZVEI, POCSAN), den Kanal (L,R) und die jeweiligen Daten angeben. Dieser Port kann simultan von mehreren Fontend-Apllikationen -- auch über das LAN -- abgehört werden. So kann ein MySQL-Frontend getrennt von einem "Classic-Client" arbeiten.

Jetzt hätte ich noch einen Vorschlag für den Daemon:
Das modulare Konzept erlaubt bislang keine @rec-Funktion, da diese vom Frondend gesteuert aber vom Backend ausgefürt werden muss.
Dazu könnte man doch das Backend mit einem TCP-Listener versehen, das auf einem zusätzlichen TCP-Port Kommandos von einem Frontend entgegen nimmt.
Beispiel: monitord gibt seine Infos wie "ZVEI:L:12345" auf localhost:10112 aus, hört aber gleichzeitig auf localhost:10113. Wenn das Frontend nun aufgrund des Regelwerks eine Funkaufzeichung anfertigen möchte, dann sendet sie eine Nachricht via Port 10113 an den monitord mit dem Inhalt:"Bitte Funk für 120 Sekunden aufzeichnen". Die eigentliche Aufzeichung übernimmt dann das Backend, welches ohnehin das /dev/dsp exklusiv belegt. Das Frontend steuert über sein Kommando, wie lange welcher Kanal aufgezeichnet wird und übergibt im Zweifelsfalle auch die sox- oder lame-Parameter an das Backend.

Der zusätzliche Port liesse sich somit auch für weitere Steueranweisungen verwenden, welche das Front- an das Backend übermitteln will.
Einschränkung: Viele Frontends können die Auswertung von Port 10112 verarbeiten aber nur EINE Frontend-Anwendung kann dem Backend zur Laufzeit via 10113 Anweisungen erteilen.

Andreas

[Buebchen]

Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden. Wäre für die Aufnahmefunktion natürlich prima, da viele Soundkarten auch den Stereo-Ausgang als Aufnahmequelle selektieren können.

Man könnte die @rec Funktion ansonsten auch über die gleiche TCP Sitzung starten/stoppen. Ist ja Bidirektional. Sollte man ggf. nur als Benutzerrecht definieren können. Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt. Die besten Aufnahme nützt nichts, wenn man sie nicht hören kann :-)

Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ? Sofern die Modularisierung da ist, ist das keine soo grosse Tat mehr.

[jhr-online]

Mir fällt gerade was auf:
Der Thread, in dem wir hier schreiben, ist u.A. betitelt mit "1.9.0". Anfangs dachte ich, das wäre die Beta-Reihe für 2.0, aber da hatten wir uns gegen entschieden, wenn ich das richtig verstanden habe. 1.9.0 ist der jetzige Stand und soll, sofern da noch jemand was dran macht, Bugfixes enthalten. So haben wir eine (mehr oder weniger) lauffähige Fassung vom monitor mit MySQL-Anbindung. Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig? Ich möchte das einfach nur aus technischen Gründen auseinander halten. Das macht die Arbeit mit subversion und BTS einfacher...

Außerdem halte ich es für sinnvoll, die Ideen mal konzeptionell zusammen zu fassen. Am Besten wär's, wenn das jemand machen könnte, der auch programmieren kann und versteht, was hier beschrieben ist (buebchen?). Wenn das geschehen ist, sollten wir tatsächlich einmal versuchen, einen gemeinsamen Chat hinzukriegen, sodass man mal abstecken kann, wer was leisten kann und will. Danach (oder meinetwegen auch davor) sollten wir das gesammelte ToDo ins BugTrackingSystem eintragen*.

Auch schön wäre ein grober Zeitplan, aber das sollten wir in den Chat verlegen, weil wir dann wissen, welche Kapazitäten wir haben.

Alles okay so?
jhr

* Aufgaben können da voneinander abhängig gemacht werden. Man kann also große Ziele und kleine als Bugs beschreiben und dann die großen von den kleinen abhängig machen. Außerdem können Aufgaben zugewiesen werden. Dadurch kann man leicht nachvollziehen, wer was macht und an wen man sich wenden muss, wenn sich was überschneidet o.Ä.

[Buebchen]

Hmm. Im Grunde wären wir dann bei Version 2.0 - Das stimmt wohl :-)

Bei der jetzigen Version 1.9 würde ich wenn nur noch Bugfixes machen. Wartung und Lesbarkeit des Source-Codes ist eine Katastrophe (oder eben nah dran).

Zur Zeit stehen wir ungefähr hier (wie schon nepomuk beschrieben hat):

Trennung von Auswertung und Anzeige / Speicherung in zwei eigenständige Programme. Als Verbindenden Element werden IP/TCP Verbindungen genutzt. Auf gleiche Weise arbeiten inzwischen fast alle Programme (Crusader, FMS32, ELS-PRO,...).

Alles weitere sind Details (grosse und kleine) zur Programmierung. Da wäre z.B. die Frage, ob schon jemand mit den Tools der Boost Lib gearbeitet hat (www.boost.org) oder jthreads (http://research.edm.uhasselt.be/~jor...?n=CS.Jthread). Um das ganze direkt auch auf mehrere Plattformen laufen lassen zu können wären das nach meiner Meinung recht geeignete Mittel (Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen).

Bei Jthreads gibt auch noch eine RTP Library. Sieht recht vielversprechend aus ( wenn sie denn auch läuft ;-)) für die Live-Übertragung von Sounddaten an die Clients.

Werde mal ein paar Diskussionbeiträge im BTS erstellen. Ist meistens einfacher zu planen, wenn es schon einen groben Plot gibt über den man streiten kann :-)

[nepomuck]

Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig?

Ja. In den 1.x-Spaghetti-Code würde ich nur noch das Minimum an Arbeit investieren. Wenn sich schon ein paar Leute gefunden haben, die aktiv an dem Projekt weiter arbeiten möchten, dann sollten wir gleich die Modularisierung und damit Version 2 in Angriff nehmen.

Auch schön wäre ein grober Zeitplan,

Der dürfte in erster Linie von Buebchen abhängen, da er die eigentlichen Änderungen im Code durchführen muss. Ich bin hier leider nur eine kleine Hilfe, da ich keinen eigenen Code zusteuern kann

aber das sollten wir in den Chat verlegen

Muss das unbedingt im Chat sein? Ich bin da kein Freund davon weil's lange dauert und eigentlich nicht viel dabei rumkommt. Wie wär's mit einer VoIP-Telefonkonferenz, via Skype oder so?

weil wir dann wissen, welche Kapazitäten wir haben.

Fang doch schon mal eine Liste an:
Buebchen: Head of Development und Meister des Codes :-)
Nepomuck: Designvorschläge, schlau daherreden, Bugfixing, Testing, Dokumentation, Live-CD bauen.
Zudem kann ich, falls erwünscht, Web-Space und Internet/Speicher-Kapazität anbieten. Ich verfüge über eine 10 MBit/s Standleitung mit ein paar festen IP-Adressen und kann ins Internet hängen was ich will. Ich würde dazu passend einen oder mehrere (auch virtualisierte) Server stellen.

Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden.

Machbar ist viel. Wir sollten uns aber für die Version 2.0 nicht zu viel vornehmen. Ich würde diese Funktion als "Kür" einstufen, die "Pflicht" ist jedoch zunächst die grundlegende modularisierung und die Kommunikation Back-Frontend.

Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt.

In der Version 2.0 soll sich da jemand anderes drum kümmern (NFS/SAMBA). Der monitord kann die Aufzeichnungen auf einem File Share sichern und das Frontend holt sie da ab. Stand heute gibt's im Frontend ja auch noch keinen integrierten Player. Das Streaming würde ich erst ein einer späteren Version berücksichtigen.

Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ?

Das sollte das modulare Konzept ja ohnehin beherrschen. Das Frondend kann über den Control-Port problemlos Anweisungen für mehr als eine Soundkarte übermitteln und dabei die jeweilige monitord-Instanz instruieren.

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt. Darüber erhält er @rec-Anweisungen, kann zur Laufzeit konfigurationsänderungen vornehmen oder ferngesteuert einzelne monitord-Instanzen starten und stoppen.
Jede monitord-Instanz steht für ein komplettes Sounddevice und damit für zwei Kanäle. Jede Instanz verfügt über einen eigenen TCP-Port, auf dem sie die Auswertungen an mehrere Frontends übermittelt.

Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen.

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Ich würde daher folgende Vorgehensweise vorschlagen:

• 1. Code entwirren und modularisieren (Buebchen)
  2. Backend "monitord" und Launcher bauen (Buebchen)
  2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
  3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
  4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
  5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
  6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
  7. Release 2.0
  7a. Release Bosix 0.2 :-)
  8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
  9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
  10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

[jhr-online]

@buebchen: Korrekt. :)
@nepomuck: Nicht zu schnell verteilen! Wir haben noch mehr Entwickler und auch noch eine Menge vor. Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist. Skype kommt mit mir nicht in die Tüte (proprietär), was nicht heißt, dass du nicht jeden anrufen darfst ;)

jhr

[nepomuck]

Nicht zu schnell verteilen! Wir haben noch mehr Entwickler

Ich wollte nur mal ein paar Basics verteilen, damit mal was vorwärts geht. Selbstverständlich sollen so viele mitarbeiten wie möglich.
Lass uns eine Liste der Projektteilnehmer zusammenstellen und dabei berücksichtigen, was wer tun kann und tun möchte.

und auch noch eine Menge vor.

Hier bitte Vorsicht: Lass uns nicht zu viel auf einmal in 2.0 planen, sonst geht das ganze irgendwann baden. Erst Pflicht, dann Kür -- und ich glaube wir sind uns in so weit einig, dass die saubere Trennung von Frond und Backend absolute Priorität hat -- wenn das steht, bleibe genug Zeit, "eine Menge" anderer Dinge dazuzuprogrammieren.

Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist.

Sehe ich ja ein.
Schlag einen Termin vor, ich kann morgen oder Fraitag sowohl tagsüber als auch mal abends oder spätabends -- immer voraus gesetzt, es brennt nicht :-)

Andreas

[Buebchen]

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt.

Ähh. Hast Du ne Zeitmaschine oder so ?

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)

Ich würde daher folgende Vorgehensweise vorschlagen:

• 1. Code entwirren und modularisieren (Buebchen)
  2. Backend "monitord" und Launcher bauen (Buebchen)
  2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
  3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
  4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
  5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
  6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
  7. Release 2.0
  7a. Release Bosix 0.2 :-)
  8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
  9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
  10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

Grundsätzlich würde ich das nicht alleine schaffen können. Deswegen bin ich froh, daß es noch andere Entwickler gitb. Neben diesem Projekt habe ich noch ein Hardware-Projekt laufen (4fach Besprechungsstelle mit Headset-Möglichkeit und PC Fernsteuerung - µC gesteuert) und ausserdem noch meinen "Dauerbrenner" Einsatzunterstützungsprogramm - der läuft schon seit Jahren. Da kommt dann auch der Windows-Port her.

zu 4: Alles was das Frontend angeht ist ManuelW unser Mann (sofern er will). Ich könnte das zwar auch noch machen aber dann würde es wohl noch einige Zeit dauern, bis ich dazu komme...

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt (monitord). Nun habe ich einen zweiten Dienst (Verarbeitungsserver) der alle "interessanten" Änderungen in der Datenbank erkennt und an die Clients, die sich per TCP verbunden haben meldet. Dies geschieht in der Form: "Änderungen FMS - Zeile 45000 ist neu, Einsatzmittel dazu hat den ID-Wert 5500". Nun kann jeder Client selbst entscheiden, ob ihn das interessiert und holt sich bei Bedarf den kompletten Datensatz aus der Datenbank.

Alles andere ist erstmal ok. Verteilung und Roadmap kommt dann sicherlich im IRC/TelCo/wo-auch-immer.

[Dove]

Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)

da möchte ich wxWidgets für C++ vorschlagen.
Damit entwickeln wir einen Sourcecode und kompilieren den unter win und unix ohne was dran geändert zu haben.

[nepomuck]

Ähh. Hast Du ne Zeitmaschine oder so ?

Nein, warum?

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt

Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.

Andreas