monitor 1.9.0 - aber richtig :)

[jhr-online]

Bin ich ebenfalls dabei.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Für dich gilt, wie für alle anderen, die mitmachen wollen:

• Schick mir eine PN mit einem Wunschpasswort, damit ich Schreibzugriff auf das Repo einrichten kann.
• Registrier dich im BugTrackingSystem und nenn mir in der PN deinen Namen, damit ich dich da zum Developer machen kann (das erlaubt auch da Änderungen und so)
• Registrier dich in der Mailingliste
• Komm ab und zu mal im Channel #fms-monitor auf irc.freenode.net vorbei

Wenn alle einverstanden sind, machen wir mal einen Termin ab, an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

jhr

PS: Danke! :)

[ManuelW]

Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Ob Montag um die Zeit klappt weiss ich noch nicht, da wollt ich an nem
Bau-Seminar in SecondLife teil nehmen :P

[nepomuck]

an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

Da bin ich in der "Offline-Pampa"
Wäre schön, wenn einer das Chat-Protokoll redigiert und den Report hier postet.

Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen. Ich habe da ein paar Ideen zu Front- und Backends sowie Kommunikationsmodulen, damit der Monitor netzwerkfähig wird. Frond- und Backend könnten dann auf getrennten PCs arbeiten, wie bei FMS Pro.

Andreas

[jhr-online]

Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Was den Termin betrifft: Das war auch nur ein Vorschlag. Scheint wohl nix zu werden, wenn sich zwei melden, weil sie nicht da sind. Andere Vorschläge?

jhr

[Buebchen]

Also, ich war im Osterstreß (der jetzt erstmal fließend in dn Kommunions-Streß übergeht). Würde aber versuchen, dabei zu sein. Am liebsten frühestens um 20:00 Uhr. Besser sogar 21:00 Uhr :-)

Mailingliste würde ich mal abwarten. Ggf. für die Entwickler unter sich. Ansonsten finde ich ist das Forum einfacher und erreicht mehr Leser.

[jhr-online]

Bin ich dabei!

An alle: Termin für ein IRC-Treffen lieber in der Woche oder am Wochenende?

jhr

[Dove]

ich behaupte mal sonntag abends 20-21 so um den dreh.
So sollten eigendlich alle zuhause sein. Denke da könnte ich auch :D

[Max K.]

Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Hi,

finds ersma toll wie du dich engagierst!

Allerdings fände ich auch toll, wenn dieses Forum hier weiter als hauptsächliche Kommunikationsplattform genutzt werden würde, weil dabei evtl. auch weniger aktive User, die nicht in der mailingliste angemeldet sind, von den Infos u. Diskussionen profitieren können..

Mfg.
Max

[jhr-online]

finds ersma toll wie du dich engagierst!

Ernst zu nehmendes Eigeninteresse... :) Und Ressourcen, die da sind, biete ich gerne für Freie Software. Ich nutze sie ja auch... Hab in den letzten Tagen auch einige GB Traffic per Torrent "geschenkt" anlässlich des neuen Debian Release :)
Wenn man mitmacht, macht es einfach noch mehr Spaß!

Allerdings fände ich auch toll, wenn dieses Forum hier weiter als hauptsächliche Kommunikationsplattform genutzt werden würde, weil dabei evtl. auch weniger aktive User, die nicht in der mailingliste angemeldet sind, von den Infos u. Diskussionen profitieren können..

Sehe ich genau so. Allerdings sind E-Mails oft praktischer, wenn sich Entwickler austauschen wollen. Wie buebchen ja meinte, könnte man später als reine Entwickler-Runde drauf zurückgreifen... Dafür biete ich die ML gerne weiter an. Für alles weitere sollte das Forum bleiben... full ack.

jhr

[nepomuck]

Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen.

Wie angekündigt poste ich hier mal ein paar konkrete Ideen für eine kommende Monitor-Version. Da meine eigenen Programmierkentnisse in C nicht wesentlich über ein "Hello World" hinausragen und ich mit Objektorientierung gar nichts am Hut habe, kann ich leider nicht aktiv am Code mithelfen, sorry.

Der Grundgedanke ist die strikte Trennung in Font- und Backend, eventuell mit einem Zwischenlayer für Netzwerkfunktionen. Der Vorteil liegt auf der Hand: Die einzelnen Module lassen sich einfacher kompilieren und jeder nutzt nur das, was er benötigt. Zudem können die Entwicklerteams von Front und Backend getrennt voneinander arbeiten, ohne den Code des anderen bearbeiten zu müssen.

1. Backend
Das Backend besteht aus einem Loader, dem Monitor-Daemon plus die Dekodierungsmodule. Die Konfiguration definiert "Channels". Jeder Channel besteht aus einem Input-Kanal wie "/dev/dsp0 links", einem Output-Kanal wie "/dev/fms0" und einer Liste der zu ladenden Module, zum Beispiel:

[channel 0]
input =/dev/dsp0 left
modules = zvei,dtfm,fms
output = /dev/fms0
[channel 1]
input = /dev/dsp1 right
modules = pocsac512
output = /dev/fms2

Der Loader prüft die Konfigurationsdatei und startet dementsprechend ein- oder mehrere "monditord"-Instanzen (eine pro Channel). Vorteil: Stürzt eine Instanz ab (siehe ZVEI-Bug), dekodiert die andere weiter.
Wichtig wäre dabei, dass das /dev/fms-Devices so deffiniert ist, dass mehrere Frondend-Tasks parallel darauf nur-lesend zugreifen können.
Auf dem Output-Device landen die dekodierten Werte im Klartext, so wie sie vom Dekodierer kommen, plus der Angabe, was dekodiert wurde, Beipsiel:
ZVEI:12345
DTFM:F
FMS:1234567:2 (<- Statusmeldung)
FMS:1234567:Text:"der übertragene Text"

Anstelle eines "/dev/fms"-Devices könnte der monitord die Ausgabe auch auf einen TCP-Port schreiben. Das würde die Netzwerkfähigkeit direkt integrieren. Lokale Frontends würden dabei dann z.B. auf 127.0.0.1:10122 hören.
Hier müssen die Entwickler entscheiden, was sich einfacher umsetzen lässt, Device oder TCP-Port.

2. Zwischenlayer
Sollte der monitord auf ein "/dev/fms"-Device schreiben, bedarf es eines Zwischelayers für Netzwerkfunktionen. Dieser würde dann auf dem Server alle Ausgaben von /dev/fms auf einem Netzwerkport bereitstellen. Im Gegenzug würden die Clients auf einem anderen PC per TCP diesen Port abhören und ein lokales /dev/fms-Device beschreiben.
Für Frontend-Anwendungen wäre es damit völlig egal, ob sie direkt auf dem monitord-Rechner oder irgendwo im LAN arbeiten -- sie müssen ja nur ein /dev/fms-Gerät abhören und darauf reagieren.
So könnte auch jemand ein Mac- oder Windows-Frontend schreiben.

3. Frondend
Hier kann jeder im Prinzip machen was er will. Es genügt, den Text-Output des FMS-Devices abzuhören und irgendwie darauf zu reagieren. Allerdings müssen Frontends multithreaded arbeiten, wenn sie mehrere Channels simultan auswerten wollen. Das "Monitor-Classic-Frontnend" würde die .monrc benutzen, um die eingehenden Informationen darzustellen, nötigenfalls umzuschreiben und darauf zu reagieren. Ein MySQL-Frontend, das parallel zu anderen arbeitet, schreibt die Auswertung in eine Datenbank. Dabei müssen sich Classic- und MySQL-Frontend nicht eine Zeile Code teilen und können friedlich nebeneinander werkeln.

Probleme:
Das Konzept berücksichtigt die REC-Funktion nicht. Die lässt sich auch nicht direkt mit dem monitord-Prozess abbilden, da dieser schließlich nur Dekodiert aber nicht auswertet. Hierfür müsste es als ein Extra Modul geben, welches zwangsläufig auf dem selben PC wie monitord arbeitet. Soweit ich weiss gibt's da aber ein Problem, dass unter Linux nur ein Task auf /dev/dsp Zugreifen kann und nicht mehrere. In diesem Fall belegt der monitord das Device exklusiv und ein getrennter recd käme nicht an die Soundkarte.

Was haltet ihr von dem Konzept?
Zumindest das Backend dürfte sich mit dem bestehenden Code sehr einfach bauen lassen. Beim Frontend müsste man den Code auseinandernehmen und die MySQL-Funktionen von "Classic"-Client trennen und als eigene Module bauen.

Andreas

[Buebchen]

Liest sich soweit ganz gut. Aber warum der Umweg über die Devices ? Ich würde dann direkt den TCP Port nehmen. Wenn es ohne TCP gehen soll wäre noch ein Unix-Filesocket vorstellbar. Ich denke, daß Du das mit dem /dev/fmsXyz meinst.

Die Idee mit den zwei Unterprozessen kann ich nur unterstützen. Habe ich in meiner Eigenentwicklung auch so umgesetzt. Wobei man es nicht 100% trennen kann.

Da man nur ein "komplettes" ein Sound-Device belegen kann muss man Links und Rechts in einem gemeinsamen Haupt-Thread erstmal von Hand trennen und kann erst dann diese Daten an die anderen Subprozesse weitergeben. Ich würde dann über den Haupt-Task auch den TCP Socket Pool verwalten und alle ausgewerteten Daten an die Clients weitergeben.

Habe bisher unter Linux nur mit Perl TCP Listener erstellt. Aber da sollten sich die C-Version von Windows und Linux hoffentlich nicht zu sehr unterscheiden.

[nepomuck]

Ich würde dann direkt den TCP Port nehmen. Wenn es ohne TCP gehen soll wäre noch ein Unix-Filesocket vorstellbar. Ich denke, daß Du das mit dem /dev/fmsXyz meinst.

Exakt. Wenn TCP einfacher ist, dann umso besser. So wird Monitor direkt netzwerkfähig und der Zwischenlayer fällt aus. Dann muss allerdings ein Modul dazu, welches die TCP-Connections zu den Clients irgendwie verwaltet und man muss sich ein wie auch immer geartetes LAN-Protokoll einfallen lassen.

Da man nur ein "komplettes" ein Sound-Device belegen kann muss man Links und Rechts in einem gemeinsamen Haupt-Thread erstmal von Hand trennen und kann erst dann diese Daten an die anderen Subprozesse weitergeben.

Das liesse sich auch so abbilden, dass ein "Channel" und damit eine monitord-Instanz zwangsläufig für zwei Sound-Kanäle steht. Dann wäre nur zu überlegen, ob der Output dann auf einem TCP-Port erfolgt, also:
ZVEI:L:12345, FMS:R:1234567:1
oder ob der Output der Sound-Kanäle auf getrennten TCP-Ports endet. Beispiele:

• [channel 0]
  input = /dev/dsp0
  modules left = ZVEI,DTFM,FMS
  modules right = POCSAC512
  output = 10112
  localonly = yes (an und abschalten des LAN-Zugriffes)

oder

• output left = 10112
  output rigth = 19222
  localonly =yes

Was anderes:
Müssen ZVEI und DTFM eigentlich als seperate Module existieren? DTFM kommt doch ohnehin immer nur in Verbindung mit ZVEI zum Einsatz. Da läge es doch nahe, diese Module zu verbinden.

Andreas

[jhr-online]

Die Thematik übersteigt meine derzeitigen Fähigkeiten ganz ordentlich, aber - nur mal leise angetastet - wäre es nicht möglich den monitord ALSA-fähig zu machen? Das dürfte doch das Sound-Problem lösen, oder nicht?

jhr

[Buebchen]

Exakt. Wenn TCP einfacher ist, dann umso besser. So wird Monitor direkt netzwerkfähig und der Zwischenlayer fällt aus. Dann muss allerdings ein Modul dazu, welches die TCP-Connections zu den Clients irgendwie verwaltet und man muss sich ein wie auch immer geartetes LAN-Protokoll einfallen lassen.

Wenn alle Stricke reissen, nehmen wir halt XML :-)

Das liesse sich auch so abbilden, dass ein "Channel" und damit eine monitord-Instanz zwangsläufig für zwei Sound-Kanäle steht. Dann wäre nur zu überlegen, ob der Output dann auf einem TCP-Port erfolgt, also:
ZVEI:L:12345, FMS:R:1234567:1
oder ob der Output der Sound-Kanäle auf getrennten TCP-Ports endet. Beispiele:

• [channel 0]
  input = /dev/dsp0
  modules left = ZVEI,DTFM,FMS
  modules right = POCSAC512
  output = 10112
  localonly = yes (an und abschalten des LAN-Zugriffes)

oder

• output left = 10112
  output rigth = 19222
  localonly =yes

Was anderes:
Müssen ZVEI und DTFM eigentlich als seperate Module existieren? DTFM kommt doch ohnehin immer nur in Verbindung mit ZVEI zum Einsatz. Da läge es doch nahe, diese Module zu verbinden.

Andreas

Würde die Ausgabe immer gesammelt über einen TCP Port machen. Man kann ja durchaus den Kanal, von dem die Info stammt mit angeben. Der Client kann dann entscheiden, ob ihn das Ergebnis interessiert.

Der Grund, daß DTMF überhaupt genutzt wird ist die m.E. Sirenentonerkennung (Doppelton). Hätte ich auch eine andere Lösung für parat (Einfach ne FFT genommen).

Ich muss mal meinen Windows C++ Source uns CVS uppen. Mal gucken, ob ich da noch irgendwelche Passwörter hard-coded drin habe. Das wäre dann nicht so geschickt :-)

Mit Alsa müßte man sich mal befassen. Wenn man einigermassen modular arbeitet sollte es nicht dramatisch sein, auf andere "Tonquellen" zugreifen zu können. Das kann ja sogar der monitor schon (Datei).

[nepomuck]

Wenn alle Stricke reissen, nehmen wir halt XML :-)

In erster Linie geht es darum, wie Client und Server sich überhaupt verständigen ("Helo" -> "Ehlo" und so was), ob es eine wie auch immer geartete Useranmeldung gibt und wie der Client regelmäßig prüft, ob er überhaupt noch zum Server verbunden ist ("ping" -> "pong").

Der Grund, daß DTMF überhaupt genutzt wird ist die m.E. Sirenentonerkennung

Klar, und die gibt's meines wissens sowieso nur bei ZVEI-Alarmierungen

Hätte ich auch eine andere Lösung für parat (Einfach ne FFT genommen).

hä? Was ist eine FFT?

Wenn man einigermassen modular arbeitet sollte es nicht dramatisch sein

Thema modular: Ich habe mir heute mal Teile des Codes angesehen, im speziellen demod_zvei.c auf der Suche nach der möglichen Ursache für das angesprochene ZVEI-Problem.
Ich will ja niemand auf die Füße treten, aber der Code ist ein wildes durcheinander: Hier etwas .monrc auslesen, dort etwas Output formatieren und mittendrin irgendwelche Cosinus-Kurven analysen.

Wenn das Projekt modular werden soll, dann muss jemand diesen Code entwirren -- bevorzugt derjenige, der in geschrieben hat. Es würde *imho* sehr viel helfen, im bestehenden Source die Backend-Funktionen zu kennzeichnen, damit man sie in mitten der Frontend-Funktionen überhapt erkennen und dann auch abtrennen kann.

Andreas