Buebchen
30.11.2007, 00:38
Um für Neueinsteiger etwas mehr Übersicht zu geben habe ich mal im Openoffice versucht, den Datenfluß im monitord darzustellen. Wichtig war mir an der Stelle auch einmal klar darzustellen, daß wir über eine Multithreaded Application sprechen und schon einiges an Komplexität drin steckt.
Die Zeichnung ist auf die schnelle Entstanden. Ich habe da auch glatt den "Supervisor"-Prozeß des monitords vergessen. Ist aber für den Datenfluß auch uninteressant.
Zum Konzept:
Pro Soundkarte wird ein Objekt der MonitorAudioXX Klasser erzeugt. Es ist abgeleitet von JThread und somit läuft es eigenständig. Dies empfängt die rohen Audiodaten der Soundkarte. Diese werden dann in einen linken und rechten Anteil geteilt und an eine zugehörige SndPipe weitergegeben.
Die SndPipe wiederum "füttert" alle Decoder-Module mit den Daten (und nach meiner Vorstellung auch optionale Plugins, wie einen Audiorecorder o.ä. - ggf. auch als gstreamer Komponente)
Die DecoderModule geben Ihre Ergebnisse - wenn sie welche haben - in eine zentrale MessageQueue im Thread GlobalDispatcher.
Der GlobalDispatcher kann nun die Ergebnisse der Auswerter an alle SocketThreads ( = verbundene Clients) und alle Plugins verteilen. SocketThreads und Plugins habe alle eine eigene Message-Queue, damit der Dispatcher nicht auf die Bearbeitung eines Datenpaktes durch die Threads warten muss.
Legende:
- Grau habe ich immer Threads dargestellt
- Bordeaux die Audiodaten
- Seeblau die ausgewerten Daten (also FMS, ZVEI, POCSAG Daten als Zahlen / Zeichen, nicht Audio)
Die Zeichnung ist auf die schnelle Entstanden. Ich habe da auch glatt den "Supervisor"-Prozeß des monitords vergessen. Ist aber für den Datenfluß auch uninteressant.
Zum Konzept:
Pro Soundkarte wird ein Objekt der MonitorAudioXX Klasser erzeugt. Es ist abgeleitet von JThread und somit läuft es eigenständig. Dies empfängt die rohen Audiodaten der Soundkarte. Diese werden dann in einen linken und rechten Anteil geteilt und an eine zugehörige SndPipe weitergegeben.
Die SndPipe wiederum "füttert" alle Decoder-Module mit den Daten (und nach meiner Vorstellung auch optionale Plugins, wie einen Audiorecorder o.ä. - ggf. auch als gstreamer Komponente)
Die DecoderModule geben Ihre Ergebnisse - wenn sie welche haben - in eine zentrale MessageQueue im Thread GlobalDispatcher.
Der GlobalDispatcher kann nun die Ergebnisse der Auswerter an alle SocketThreads ( = verbundene Clients) und alle Plugins verteilen. SocketThreads und Plugins habe alle eine eigene Message-Queue, damit der Dispatcher nicht auf die Bearbeitung eines Datenpaktes durch die Threads warten muss.
Legende:
- Grau habe ich immer Threads dargestellt
- Bordeaux die Audiodaten
- Seeblau die ausgewerten Daten (also FMS, ZVEI, POCSAG Daten als Zahlen / Zeichen, nicht Audio)