2.1 und @rec

[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