2.1 und @rec

[nepomuck]

Da unser Main-Thread langsam an Übersicht verliert, lagere ich meine Anfrage als neues Thema aus.

Wie lösen wir denn jetzt mit der Client/Server-Struktur das Problem mit dem @rec-Kommando?

Ich hätte folgenden Vorschlag:
monitord implementiert die Funktion und in monitord.xml gibt es einen entsprechenden Konfigurationsabschnitt, der SOX-Parameter Aufzeichnungspfad etc.. festlegt.

Der Client kann über das Kommando 230 den Server anweisen, den Funk aufzuzeichnen, Syntax:

230:(Soundkarte):(Kanal):(Dauer Sec):(Dateiname HEX)
evtl. könnte man weitere REC-Parameter anhängen.

Der Server antwortet mit Kommando 130 als Statusmeldung, gibt dabei an "1" für Aufnahme läuft, nach Ablauf der Zeit eine "0" für Aufnahme beendet oder "9" für Fehler

130:(Uhrzeit):(Status):(Dateiname)

Der Client kann dann, je nach Konfiguration, die aufgezeichnete WAV-Datei per SMB/NFS/FTP abholen.

wie wäre das?

Andreas

[jhr-online]

Ich wäre eher für eine Antwort mit verschiedenen Codes. Also 130 für beginnende Aufnahme, 131 für endende Aufnahme und meinetwegen 139 für Aufnahmefehler. Dann muss nur noch der Timestamp mitgesendet werden.

Man könnte sogar, wenn man will, den monitord flexibel machen, indem er nicht nur unter Angabe einer Dauer aufzeichnet, sondern auch 230 als einfaches Startsignal und 231 als Endsignal annimmt. Dann kann der Client situationsabhängig selber entscheiden, was er braucht. Damit man bei einem Client-Absturz die Platte vom Server nicht volllaufen läßt, sollte man in dem Fall in der xml und/oder per CommandLine-Parameter eine Maximallänge festlegen können.

[nepomuck]

Ich wäre eher für eine Antwort mit verschiedenen Codes. Also 130 für beginnende Aufnahme, 131 für endende Aufnahme und meinetwegen 139 für Aufnahmefehler. Dann muss nur noch der Timestamp mitgesendet werden.

Geht auch, aber der Timestamp alleine genügt nicht. Es könnten mehrere Aufzeichnungen parallel laufen und der jeweilige Status vom Server muss zurückliefern, für welche Aufzeichnung die Meldung gilt.

Man könnte sogar, wenn man will, den monitord flexibel machen, indem er nicht nur unter Angabe einer Dauer aufzeichnet, sondern auch 230 als einfaches Startsignal und 231 als Endsignal annimmt.

Das halte ich für eine unnötigen Mehraufwand für den Client. Sollte der Client wider Erwarten feststellen, dass er länger als ursprünglich geplant aufzeichnen will, dann sendet er das Rec-Start-Kommando einfach nochmal und der Server verlängert die Aufzeichnung entsprechend. Diese Funktion ist ja in der 1.8.1 bereits eingebaut.

Andreas

[jhr-online]

Geht auch, aber der Timestamp alleine genügt nicht. Es könnten mehrere Aufzeichnungen parallel laufen und der jeweilige Status vom Server muss zurückliefern, für welche Aufzeichnung die Meldung gilt.

Ich habe zu wenig Ahnung davon; sich überschneidende Aufnahmen mehrerer eingelogter Clients sind kein Problem?

Das halte ich für eine unnötigen Mehraufwand für den Client. Sollte der Client wider Erwarten feststellen, dass er länger als ursprünglich geplant aufzeichnen will, dann sendet er das Rec-Start-Kommando einfach nochmal und der Server verlängert die Aufzeichnung entsprechend. Diese Funktion ist ja in der 1.8.1 bereits eingebaut.

Das bedeutet aber, dass der Client (und damit der Benutzer) wissen muss, wie lang die Aufnahme sein soll. Bei automatischen Aufnahmen ach Alarm o.Ä. ist das ja oft der Fall, aber ich könnte mir vorstellen, dass man auch mal live schnell eine Aufnahme machen will und dafür einfach einen Knopf drücken können will.
Es ist ja nur ein zusätzliches Feature, das ich gerne hätte und prinzipiell, wenn man es jetzt schon sauber implementiert, nicht viel Mehraufwand sein kann, oder?

[nepomuck]

sich überschneidende Aufnahmen mehrerer eingelogter Clients sind kein Problem?

Hmmm, wahrscheinlich schon. Der Status vom Server sollte auch noch eine Client-ID mitgeben, damit die Clients wissen, wessen Aufzeichnung läuft oder fertig ist.

Ein Problem dürfte sich allerdings ergeben, wenn mehrere Clients simultan auf einem Kanal aufzeichnen wollen.

Mögliche Lösungen:
1. Läuft bereits ein REC-Vorgang, meldet der Server "Busy" und lehnt damit die Aufzeichnung ab. Das ist die einfachste Lösung, wenn auch die schlechteste.

2. Der Server verlängert die bereits laufende Aufzeichnung um die vom 2./3./4. Client gewünschte Zeit und schneidet am Ende die Gesamtaufzeichung in die jeweils geforderten Abschnitte auseinander und speichert sie als einzelne Dateien mit dem jeweils vom Client geforderten Namen. Das wäre die Beste Lösung, dürfte aber auf der Serverseite recht aufwändig zum Umsetzen sein (Buebchen ????)

3. Der Server gibt eine Statusmeldung "Already Recording" zurück mit dem Dateinamen der bereits laufenden Aufzeichnung. So kann der Client statt der von ihm angeforderten WAV-Datei diejenige herunterladen, welche ein anderer Client vorher in Auftrag gegeben hat.

Die Variante ist einfacher für den Server, fordert aber mehr Intelligenz vom Client.

Ich würde Lösung 2 vorziehen -- entscheiden muss das aber einer von den Leuten, welche den Code schreiben.

aber ich könnte mir vorstellen, dass man auch mal live schnell eine Aufnahme machen will und dafür einfach einen Knopf drücken können will.

Klar. Wenns kein zu großer Aufwand zum Programmieren ist.

Andreas

[jhr-online]

Gibt es nicht dank ALSA und Co. noch Möglichkeit 4: Simultaner Zugriff auf Sound Devices?

jhr

[nepomuck]

Gibt es nicht dank ALSA und Co. noch Möglichkeit 4: Simultaner Zugriff auf Sound Devices?

Das entspräche dann Lösung 2: Statt einem REC-Thread der im Nachhinein die WAV-Datei zerlegt, nehmen mehrere Threads parallel auf.
Einfacher zu programmieren, braucht dafür mehr Ressourcen.

Frage an die Code-Entwickler: Funktioniert das?

Andreas

[Buebchen]

Hmm. Meine Idee (was auch ins bestehende Konzept ganz gut passt):

Es gibt eine "Auswerter"-Klasse für die Aufnahme. Die wird einmal oder mehrmals als Modul (Objekt) erzeugt.

Jedes Modul macht eine Datei und weiß, wann es mit der Aufnahme aufhören soll. Die kommen dann in eine Warteschlange (technisch: vector) und bekommen dann schön nacheinander die digitialisierten Daten übergeben. Dann kann jedes Modul für sich die Aufnahme auf die HDD schreiben. Egal, was die anderen machen.

Ist die Aufnahme fertig müßte sich das Modul aus der Warteschlange abmelden.

Ungefähr so:

Sound-Device (Block aus Float-Werten) -> [Auswerter-Module] -> Aufnahmemodul 1 -> Aufnahmemodul 2 -> Aufnahmemodul 3 ...

Muss ja nicht jedes Modul für sich ständig neu digitialisieren. Machen die Auswerter auch nicht. Die bekommen die digitalen Daten auch fertig präsentiert.

[jhr-online]

Nur zum Verständnis: Will man denn digitalisierte Daten aufnehmen? Ich dachte für die Aufnahme nimmt man die Rohform...

Ach, und was meinst du von der Protokoll-sache? Aufnehmen nur mit Zeitangabe oder auch endlos?

jhr

[nepomuck]

Sound-Device (Block aus Float-Werten) -> [Auswerter-Module] -> Aufnahmemodul 1 -> Aufnahmemodul 2 -> Aufnahmemodul 3 ...

OK. heißt das (in Kurzform für die anwesenden Nicht-entwickler wie mich):
monitord kann ohne probleme x-fach parallel aufzeichnen?

Folglich könnten diverse Clients parallel REC-Kommandos an den Server senden.

Um die Clients dann im Protokoll auseinanderzuhalten müsste man eine Art "Auftrags-ID" festlegen, damit der Client später seinen Aufzeichnung findet. Das würde gewährleisten, dass a) mehrere Clients parallel und b) ein Client parallel mehrere Kanäle aufzeichnen können.

Beispiel:

C->S (aufnahme start timed)
230:(Soundkarte):(Kanal):(Dauer Sec):(Dateiname HEX)
oder
C->S (aufnahme start infinite)
231:(Soundkarte):(Kanal):(Dateiname HEX)

wobei man sich da ein Kommando sparten könnte und einfach 230 mit Zeitangabe 0s übermittelt, um eine langfristige Aufnahme anzuleiern

S->C (aufnahme gestartet)
131:(Dateiname HEX):(Auftrags-ID) -- die ID erstellt der Server so quasi aus einer Kombo: IP des Clients plus /dev/random

...danach...

S->C (Aufnahme fertig)
132:(Dateiname HEX):(Auftrags-ID)

zwischendrin könnte dann auch noch kommen:
C->S (Aufnahme abbrechen)
239:(Dateiname HEX):(Auftrags-ID)
S->C (Aufnahme fertig)
132:(Dateiname HEX):(Auftrags-ID)

oder der Client sendet das 230er Kommando nochmal und der Server verlängert einfach den REC-Vorgang.

klingt das plausibel?

Andreas

[Buebchen]

Das trifft genau den Kern der Idee. Wie man das ganze jetzt im Client am besten regelt ? Tja, das ist noch zu definieren.

Ggf. müßte man so eine Art "Aufnahme-Manager" schreiben. Denn jeder Client hat seinen eigenen Thread, der ihm Daten sendet und seine Anfragen erstmal bearbeitet.
Jetzt könnte der Thread dem AM irgendwie mitteilen:" Hey, mach mal ne Aufnahme ...". Das "irgendwie" müßte noch definiert werden.

Ähnlich stelle ich mir später auch den direkten Live-Audiostream vor. Wobei das noch etwas knifflig ist, die Daten zum Client zu bekommen.

Ansonsten glaube ich, könnte das so einigermassen laufen. Ggf. wird das nur bei kleinen CPUs schnell das System überlasten. Muss man dann mal austesten...

[nepomuck]

Das trifft genau den Kern der Idee. Wie man das ganze jetzt im Client am besten regelt ? Tja, das ist noch zu definieren.

Halte ich für simpel. Der Client erledigt die Auswertung und setzt das REC-Kommando ab. In der Client-Konfig hinterlegt der admin, in welchem LAN-Pfad die Rec-Dateien dann zu finden sind. Um das mounten des LAN-Pfades muss sich vor dem Client-Start der Anwender kümmern.

Ggf. müßte man so eine Art "Aufnahme-Manager" schreiben.

Wo. Auf dem Client oder Server?

Ähnlich stelle ich mir später auch den direkten Live-Audiostream vor.

Wobei ich immer noch glaube, dass man hier nicht das Rad neu erfinden und was Neues programmieren muss. Hier liesse sich doch sicher was bestehendes wie VLC nutzen. Das ist Open Source und unter Win, Mac und Linux verfügbar.

Ansonsten glaube ich, könnte das so einigermassen laufen. Ggf. wird das nur bei kleinen CPUs schnell das System überlasten.

Parallele Aufzeichnungen von zwei bis drei 22-khz-Mono-Streams sollten auch alte 300-Mhz-P2-CPUs noch hinbekommen.

Andreas