Zitat Zitat von nepomuck
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 :-)

Zitat Zitat von nepomuck


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).