monitor 1.9.0 - aber richtig :)

[Buebchen]

Ne, Ne. Schon beim monitor waren das getrennte Dekodierer. Für jede "Spezies" einer.

Parallel habe ich bisher nur die Kanäle laufen lassen. Ob es Sinn macht, das auf die einzelnen Auswerter herunterzubrechen ... muss man mal drüber nachdenken. Ich würde Spontan nur linken und rechten Kanal als einzelnen Prozeß laufen lassen. Wobei man natürlich auch mehr als zwei Prozesse bilden kann (um z.B. mehrere Soundkarten auszuwerten).

[Dove]

ich glaube um die modularsierung zu wahren sollte man die einzelt lassen.
So kann man dann eventuell auch das laden der für mich wichtigen module einstellen und alle anderen module werden außen vor gelassen.

[Buebchen]

Reden wir jetzt von logischen Modulen oder von real existierenden Prozessen ?

Ich würde die Module trennen, keine Frage. Das ist im monitor sowieso schon so, also keine Änderung. Ich würde nur für den linken und rechten Kanal (ggf. auch weitere) immer einen Unterprozeß (Thread) bilden. Hängt sich ein Kanal weg, läuft der andere weiter. Ausserdem würde man so zumindest ein Stückchen von HT / Dualcore profitieren.

[Dove]

Reden wir jetzt von logischen Modulen oder von real existierenden Prozessen ?

Ich würde die Module trennen, keine Frage. Das ist im monitor sowieso schon so, also keine Änderung. Ich würde nur für den linken und rechten Kanal (ggf. auch weitere) immer einen Unterprozeß (Thread) bilden. Hängt sich ein Kanal weg, läuft der andere weiter. Ausserdem würde man so zumindest ein Stückchen von HT / Dualcore profitieren.

genauso seh ich das auch.

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