Voice-/Sprach-Chat

**onepiecefreak2**

Ok, also jetzt reicht's mir.

Ich mag vllt. kein ausgeprägtes Wissen über Server/Client-Verbindungen oder einen VoiceChat-ähnlichen Aufbau haben, aber dass ich mich hier am Code anderer bereichern will und ihn als meinen ausgeben würde, verbitte ich mir. Perlsau ich habe die Datei von Aphton von Anfang an im uses-Bereich eingebunden. Es ist demnach nicht mir vorzuwerfen, dass die ganzen Fehler auftreten. Auch dass die ganzen Fehler unbedingt an Stellen auftauchen müssen, von denen ich noch keine große Ahnung habe, ist mir persönlich sehr unangenehm. Wie würdest du dich als Anfänger in diesem Bereich fühlen, der trotz aller Hilfen die womöglich einfachsten Fehler nicht lösen kann?

Also du hast deine Meinung, finde ich auch voll in Ordnung, aber mir damit zu kommen, dass ich nichts von dem verstehe, was hier steht, ist wirklich unfair. Außerdem bin ich schon viel weiter in der bass.dll-Programmierung und habe auch schon eigene Ideen. Und als Letztes, den Code von Aphton umzubauen ist für mich der ultimative Lernprozess. Ich habe gelernt wie man das Aufnahmegerät einbindet, den Ton streamt und versendet. Es sind eben noch Kenntnisse nötig, um alles verstehen zu können, aber dafür bin ich ja hier und bitte um Hilfe!

So und um dieses "Gezanke" hier abzuschließen: Ich werde den Code von Aphton weiter benutzen, "auch wenn es der Weg des geringsten Widerstands ist". Für mich, der keine Ahnung hat, muss man eben das nehmen was man kriegen kann und das ist mir durch Aphtons Beispiel gegeben. Wie gesagt eine Lerngrundlage.

So, und nun verbitte ich mir diese Offtopic hier. Schließlich wollen wir doch friedlich zusammenleben, oder nicht?

**onepiecefreak2**

Und nochmal zu Aphton's Antworten zu meinen Fehlern:
Ich habe deine Datei im uses-Bereich eingebunden. Alle Fehlercodes in meinem vorletzten Post sind nach dem Einbinden aufgetaucht. Und das Geruckle vom Ton ist schon in deiner Konsolenvariante vorhanden. Ich habe sie (natürlich unverändert, da ich ja deine .pas noch nicht hatte) gestartet, konnte mich selbst hören und war nur ruckelig selbst zu verstehen. Vllt. liegt das Geruckle auch daran, da es gerade meine Wenigkeit war die Server und Client war?

Naja, immernoch dankbar für alle Hilfen.

**Aphton**

Nun das "geruckle" ist dadurch da, weil ja zwei Aufnahmen/Wiedergaben parallel stattfinden, wenn mans lokal auf einem einzigen Rechner testet:
Client -> Server
Server -> Client
(Aufnahmequelle bei beiden ist dein Mikrofon)

Teste es lieber mit 2 Rechnern.. Da soltle das "Ruckeln" nicht mehr da sein. (Sollte im Grunde auch kein Ruckeln sein; du solltest dich zeitversetzt zweimal hören)

**onepiecefreak2**

Ja genau so war es. Ich habe mich 2mal gehört. Kann ich mithilfe meiner IP-Adresse eine Schleife erzeugen, die mich als Empfänger meines eigenen Tons ausschließt? Weil ich muss ja selbst auch einen Client laufen haben, sonst kann ich mit meinem Freund ja nicht sprechen. Ich bin aber auch der, der den Server laufen lässt.

Wenn das so machbar ist, ist das kein Problem, aber vllt. ist es auch komplizierter.

@Aphton
Die Fehler in meinem nun vorvorletzten Post sind NACH der Einbindung deiner .pas-Datei aufgetreten. Ich habe da reingeschaut und bemerkt, dass die Funktion SendBuffer aber vorhanden ist. Warum erkennt er diese Funktion nicht?

P.S: Aphton, ich finde dein Profilbild einfach Hammer. Wollte ich nun endlich mal loswerden.
P.P.S: Death Note 4 ever

**himitsu**

Das mit der Rückkopplung ist halt etwas schwierig.
Wenn das drüben aus einem Lautsprecher raus kommt, dann ist es problemlos mölgich, daß deine Sprache beim Anderen ebenfalls im Mikro landet.

Im günstigsten Fall hat Einer 'nen headset und hört nur einmal sein eigenes Echo.
Oder es kommt leiser zurück und das Echo verlischt nach einer oder mehreren Runden.
Oder es kommt lauter zurück und das Echo baut sich so auf, bis alles übersteuert und dir die Ohren explodieren.

Jetzt kann man billig hingehn und programmseitig einfach das Mikro abschalten, solange eine (lautere) Tonausgabe kommt.
Oder man analysiert die Stärke der Tonausgabe und regelt das Mikro provisorisch adaptiv runter, so daß es keine "großen" Rückkopplungen gibt.
Oder du bist der krasseste Programmierer, analysierst die Mikrofonaufnahmen, suchst nach einer eventuellen Einkopplung der Tonausgabe und rechnest diese aus dem aufgenommenden Audiostrem raus.
Gut, es geht auch einfacher und man versucht nur "größere" Rückkoplungen zu erkennen und regelt dann Mikro und/oder Lautsprecher so weit runter, bis die Rückkopplung weit genug reduziert ist.

**onepiecefreak2**

Ich glaube du hast das Problem falsch verstanden. Ich habe es bis jetzt nur mit mir selbst über ein Headset getestet. Ich habe mich selbst in der Lautstärke gehört mit der ich aufgenommen habe, es ist also keine Rückkopplung. Das was Aphton sagte, es würde daran liegen, dass ich sowohl Server als auch Client bin, kann ich mir gut vorstellen. Mein Problem war ja das der Server mein eigenes Gesprochenes nicht mehr an mich zurücksenden soll. Und das wollte ich halt über eine 'IP-Sperre' machen. Also, der Server liest den Ton und meine IP und verschickt den Ton dann an alle Clients außer an den mit der, dem Ton mitgeschickten, IP.

**himitsu**

Das ist bei dem Problem irrelevant, also ob du nun direkt mit dir sprichst oder nur indirekt, über einen anderen Computer.
Du hast auch letztendlich 2 Programme und wo die laufen ist grundsätzlich erstmal egal.
Die Techniken, wie man Echo/Rückkopplung unterdrücken kann, bleiben im Prinzip ja die Gleichen.

'ne zusätzliche IP-Sperre ist eh nicht so sinnvoll. (es gibt eh genug wichtigere Dinge, die du noch machen musst)
- erstmal ist das hier nur ein zu vernachlässigender Sonderfall (normaler Weise macht man sowas ja nicht)
- dann blockiert man sich so eine lokale Möglichkeit das schnell mal zu testen
- ich hab daheim 2 und an einem Rechner sogar aktuell 3 (bis 5) Wege ins Internet, welche alle gleichzeitig aktiv sein können. Also mehrere interne und öffentliche IPs. Was willst du da dann prüfen?
- es können mehrere Rechner an der selben öffentlichen IP hängen
- lokal, können Beide sogar die gleiche IP besitzen -> Frag hier mal rum, wer eine 192.168.178.* bei seinem Rechner hat. (da finden sich bestimmt welche mit der Gleichen)

**Aphton**

Ich habs ja bei der Demo so, dass die Anwendung nach Wahl als entweder Server oder Client fungiert.
Du müsstest nun die Logik soweit trennen und Auslagern, dass du eine eigene Server-Exe und eine eigene Client-Exe hast.
Ich versteh aber nicht genau, warum du das unbedingt so haben willst. So wie es momentan ist, find ichs eig. viel besser.

Konkreter nun - du müsstest beim Client folgendes machen:
- Verbindungsaufbau zum Server
- Mikrofondaten, die vom Capture Thread geliefert werden, direkt an den Server ununterbrochen weiterleiten (einfach in den Sendbuffer hauen, da der sowieso abgearbeitet wird)

Server:
- Verbindungen aufnehmen und in eigene Threads auslagern (das wäre komplett neu zu machen, da bei der Demo nur eine einzige Verbindung erlaubt ist, designtechnisch)
- Pro Thread Mikrofondaten empfangen und sofort an alle anderen Clients weiterleiten - somit hört jeder jeden Teilnehmer

Edit:

Zitat:

@Aphton
Die Fehler in meinem nun vorvorletzten Post sind NACH der Einbindung deiner .pas-Datei aufgetreten. Ich habe da reingeschaut und bemerkt, dass die Funktion SendBuffer aber vorhanden ist. Warum erkennt er diese Funktion nicht?

Zum Fehler - ich kann dir da nicht helfen. Vlt ginge es, wenn du mal die Delphi-Fehlermeldung kopierst und hier postest (ctrl+c sollte funzen)

**mjustin**

Zitat von onepiecefreak2:

Also, der Server liest den Ton und meine IP und verschickt den Ton dann an alle Clients außer an den mit der, dem Ton mitgeschickten, IP.

Bei TCP wird eine Client-Server oder Peer-to-Peer Verbindung anhand der Kombination aus IP Adresse und Port eindeutig identifiziert. Die Socket-Verbindung, die den Ton nicht erhalten soll, kann man so identifizieren. Jeder Client erhält dabei bei TCP einen dynamisch vergebenen Port, wodurch alle Clients sich unterscheiden lassen.

Je nach TCP Bibliothek ist das aber nicht die einzige Möglchkeit, Clients zu identifizieren. Der Indy TCP Server ermöglichen es beim Verbindungsaufbau vom Client zum Server jedem Client eine ID zuzuweisen, deren Wert man selbst vergibt. Will man eine Nachricht an einzelne oder eine Gruppe von Verbindungen senden, kann man die IDs aller bestehenden Verbindungen der Reihe nach mit den "gewünschen" Empfänger-IDs vergleichen.

**onepiecefreak2**

@Aphton
Das ist der Fehler:
[Fehler] Unit1.pas(264): Undefinierter Bezeichner: 'SendBuffer'

Aber, wie gesagt: Da ist deine .pas schon eingebunden und in der finde ich die Funktion SendBuffer. Warum also Delphi nicht?

@mjustin
Ich werde das mal bei meinem TextChat einbauen. Sollte es da gehen, werde ich später auch im VoiceChat irgendwie so hinbekommen.

Wer mir da jetzt wieder ein Strich durch die Rechnung machen will und schreibt, dass bei einem VoiceChat so eine Sperre anders gehen muss, lässt das bitte. Ich will wenigstens das alleine hinbekommen. Danke!