Voice-/Sprach-Chat

[onepiecefreak2]

Liebe Community,

ich bin schon seit mehreren Jahren im Programmieren tätig. Dies beschränkt sich auf alles Lokale was mit Delphi möglich ist. Nun versuche ich mit meinem Delphi 5 Standard einen Voice-Chat zu programmieren. Bisher habe ich einen Text-Chat fertiggestellt. Zumindest funktioniert er von der Übermittlung der Nachrichten her. Nun will ich diesen um einen Voice-Chat erweitern.

Ich habe wie gesagt, schon fortgeschrittenes Wissen mit Delphi 5 Standard und grundlegende Kenntnisse zu Server/Client-Verbindungen.
Ich besitze 3 Versionen von Delphi 5 Standard: Einmal ohne Indy und zweimal mit Indy (9 und 10).

Meine Frage wäre: Mit welchen (Zusatz-)Komponenten und welchen Aufrufen von Devices etc. ist eine solche Liveübertragung von Ton möglich? Sollte es Zusatzkomponenten geben, wären gute Tutorials zur Benutzung dieser erwünscht. Am Allerbesten wären auch Codebeispiele. Allerdings sollten diese Beispiele auch Kommentare enthalten. :)

Wenn ich mir anmaßen darf zu sagen, dass es mir wenig weiterhilft, wenn ihr "nur" Fachbegriffe verwendet. Sollten die Befehle oder Komponenten nicht durch ihren Namen oder ähnliches schon ausreichend erklärt sein, wäre ich euch ebenfalls für Erklärungen diesseits dankbar. Das gleiche würde bei Codebeispielen gelten.

Ich würde mich sehr darüber freuen, wenn wir in diesem Thread einen funktionstüchtigen Voicechat fertig gebastelt bekommen. Sollte es irgendwelche Fragen geben, fehlen euch Informationen zu meinem Delphi oder ähnliches oder sind euch meine "Anforderungen" zu grob/zu ungenau, schreibt es in den Thread.

Ich habe jetzt Zeit en masse. Und da ich Fachinformatiker lerne, ist so ein Voicechat ein guter Anfang in Sachen Netzwerkübertragung/Liveübertragung.

Solltest du bis hierher gelesen haben, hoffe ich, dass du Ahnung hast und mir helfen kannst. Der Chat den ich schon fertig habe, habe ich aus Gründen zur Komplettheit mit an diesen Thread angehangen.

P.S: Bevor jemand was sagt oder meckert. Ich suche schon seit mehreren Tagen das ganze Inet durch und auch das Forum hier. Dennoch ist es nie ein Thread genau über einen Voice-Chat. Daher fehlen mir die Zusammenhänge zwischen den ganzen Erklärungen und Codeschnipseln. :cry:

[nuclearping]

Beispiele findest du hier:

http://lakeofsoft.com/vc/a_voicechat.html
http://www.torry.net/pages.php?id=207

Ist kein einfaches Thema. Das Hauptproblem ist die effiziente Ausnutzung der zur Verfügung stehenden Bandbreite, zum einen durch intelligente Pufferungsmechanismen und zum anderen durch die Verwendung entsprechender Codecs.
Und solange genug Bandbreite zur Verfügung steht, ist das weniger ein Problem. Aber du musst bedenken, dass Voice Chats in der Regel zum Spielen eingesetzt werden und der Datenstrom dabei so gering wie möglich sein sollte, um den Ping nicht negativ zu beeinflussen, ohne dabei aber auch zur sehr an Qualität zu verlieren.

[Mavarik]

Hi!

Da hast Du Dir eine nicht gerade einfache Aufgabe ausgesucht.

Auch wenn ich ein Freund davon bin, dass Rad neu zu erfinden. Würde ich Dir empfehlen ggf. ein Interface für TeamSpeak oder Skype
zu nehmen.

Selbst wenn Du einen fertigen Codec nimmst, die Sache mit dem Timing, Latenz, Bandbreite, Sprachqualität usw. verlangt schon 2-3 Threads die alle "richtig" Synchronisieret werden müssen.

Im lokalen 1000er Netzwerkt mit dauersenden kein Thema, aber wenn es darum geht gemäß eine Vorgabelautstärke nur zu senden, wenn auch gesprochen wird, wird es schon komplizierter (war bisher meine Hürde). Bei (push to talk) wäre da einfacher.

Mavarik

[onepiecefreak2]

@nuclearping
Danke erstmal für die Antwort.

Der Chat soll hauptsächlich zur Kommunikation im Allgemeinen (also außerhalb von Spielen erstmal) genutzt werden. Erstmal soll er nur funktionieren, heißt Optimierung und weniger Bandbreite nutzen, kann auch noch "später" gemacht werden.

Ich werde mir mal die Seiten und Beispiele anschauen. Werde mich melden sobald ich Fragen zu den beiden Seiten habe.

@Mavarik
Über die Komplexität bin ich mir bewusst. Mein Ziel ist dennoch "simpel" gehalten. Es soll zuallererst über haupt eine Verbindung stehen über die live Ton versendet wird. Ob es nun asynchron ist oder der Ton knackt ist dabei erstmal egal. Sobald eine solche Verbindung besteht, lassen sich diese "Feinheiten" immernoch einbringen.

Das ist meine bescheidene Meinung. Oder glaubt ihr diese Optimierungen MÜSSEN im Vorfeld getroffen werden? Glaube ich nämlich nicht.

[BUG]

Im großen Ganzen her gesehen brauchst du drei Sachen:

• Aufnahme/Wiedergabe von unkomprimierten Soundaten
• einen Codec (z.B. MP3 oder OPUS)
• ein Netzwerkprotokoll (z.B. RTP)

Da es quasi kaum zu schaffen ist, das alles selbst zu programmieren, musst du dich einschränken. Es wäre auch möglich das du zB. das Netzwerkprotokoll selbst entwirfst, allerdings sollte schon das richtige "Zusammenstecken" fertiger Implementierungen nicht ganz einfach sein.

Die Sache mit dem "erstmal laufender Prototyp" ist die: Codecs und Echtzeitübertragung sind nicht ganz einfach und du kannst dann leicht in die Situation kommen, dass du merkst, das du deinen bisherigen Entwurf quasi wegschmeißen musst, um es ordentlich zu machen.

[onepiecefreak2]

@BUG
Mir ist es schon oft passiert, dass ich alles wegwerfen muss. Das mach ich sogar lieber als immer wieder was im Code zu ergänzen. Wenn ich den Code dann immer wieder neu schreibe, bekomm ich manchmal sogar neue Einfälle zur Optimierung.

Ich glaube bevor hier mehr "allgemeines" Wissen ausgetauscht wird :P (nicht so ernstnehmen ;)), würde ich sagen stellen wir eine Schrittfolge auf.

Machen wir erstmal die Aufnahme vom Mikrofon. Wie ist das zu bewerkstelligen? Welche Komponenten? Und gibts Beispiele dazu?

@nuclearping
Die Seiten habe ich mir angeschaut und bin noch am Durchlesen und Probieren. Sollte sich darin die Lösung für die Aufnahme befinden, werde ich es hier sagen. Ansonsten, lasst die Ideen strömen. :wink:

[nuclearping]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262287)

@BUG
Mir ist es schon oft passiert, dass ich alles wegwerfen muss. Das mach ich sogar lieber als immer wieder was im Code zu ergänzen. Wenn ich den Code dann immer wieder neu schreibe, bekomm ich manchmal sogar neue Einfälle zur Optimierung.

Wenn du einfach nur rumprobieren und experimentieren willst, spricht nichts dagegen. Aber wenn du wegen fehlender Strukturierung, Planung und Modellierung ständig Codes verwirfst, ohne mit deinem Projekt wirklich vorwärts zu kommen, ist das längerfristig frustrierend.

Du solltest dir jetzt unbedingt schon Gedanken machen, wie du Protokolle, Klassen und Threads entwirfst, um die verschiedenen Aufgaben (Aufnahme, Wiedergabe, Komprimierung, Dekomprimierung, Senden, Empfangen, ...) zu erledigen, wenn du das Projekt irgendwann in nächster Zeit auch mal soweit haben willst, dass es läuft.

Und wenn du dir schon so ein komplexes und kniffliges Projekt raussuchst, sollte auch ein gewisser und halbwegs vertrauter Umgang mit den dazugehörigen Themen gegeben sein. Ohne an dir zweifeln zu wollen, aber wenn du schon danach fragst, wie man Sachen vom Mikrofon aufnimmt und welche Komponenten man dafür braucht, dann sind das keine guten Vorraussetzungen. Oder? :mrgreen: :cheers:

[onepiecefreak2]

Ja, mag schon stimmen. Dennoch ist in deinem Post ein guter Ablaufplan vorhanden. Wenn ich diesen Ablauf Stück für Stück abarbeite, wäre es möglich mein Wissen entsprechend auszubauen.

Natürlich ist es eine dumme Frage nach Aufnahme- oder Wiedergabekomponenten. Ich glaube dazu könnte ich noch was finden. Das Senden und Empfangen kann ich ja schon mit Strings. Allerdings ist es ja ein Unterschied ob ich nun mit SendText und ReceiveText einen String versende oder mit anderen Befehlen eine Audiodatei. Demnach ist das Senden und Empfangen wohl noch eine Frage für diesen Thread hier.
Andererseits noch eine Frage: An welchem Punkt muss die Komprimierung/Dekomprimierung stattfinden?

Ich danke für eure Mühen bisher!:-D

[onepiecefreak2]

Um den aktuellen Status zu Seite zu bringen: Ich habe nun die Aufnahme von Ton in Delphi gebracht.

Das ist der Code dazu. (Sollte der dem einen oder anderen bekannt vorkommen, ich habe ihn aus diesem Thread entnommen: http://www.delphipraxis.net/7803-sound-aufnehmen.html)

Delphi-Quellcode:

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls, mmSystem;   //Die Unit mmSystem muss hier stehen, sonst sind die Befehle nicht zu nutzen.

//...

implementation

{$R *.DFM}

procedure TForm1.Button1Click(Sender: TObject);
begin

//Aufnahme des Tons.
     mciSendString('OPEN NEW TYPE WAVEAUDIO ALIAS mySound',nil,0,Handle);
     mciSendString('SET mySound ' +
                   'TIME FORMAT MS ' +
                   'BITSPERSAMPLE 16 ' +
                   'CHANNELS 2 ' +
                   'SAMPLESPERSEC 44100 ' +
                   'BYTESPERSEC 176400 ' +
                   'ALIGNMENT 4',
                   nil,0,handle);
     mciSendString('RECORD mySound',nil,0,Handle);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin

//Beenden der Aufnahme und Speichern der Datei.
mciSendString('STOP mySound',nil,0,Handle);
     mciSendString('SAVE mySound "c:\datei.wav"',nil,0,Handle);
     mciSendString('CLOSE mySound',nil,0,Handle);
end;

Nun versuche ich diese Datei zu konvertieren und will am Besten LAME benutzen. Wie kann ich das Einbinden? Sollte das nicht gehen, wie kann ich das sonst aus dem Programm heraus realisieren?

P.S: Ich habe mich derweil ein wenig in das Thema "Threads" reingelesen. Heißt, ich kann diese Konvertierung auch in einem Thread laufen lassen, was mir doch sicher geraten wird, oder?

[himitsu]

Also so kannst du das wohl gleich wieder vergessen.

Was willst du denn damit machen?
Jeweils 1-x Sekunden aufnehmen, das danach speichern, umwandeln und dann auch noch übertragen?
Erstmal gibt es dann entweder ständig Aussetzer, wenn du die Aufnahme immer wieder stoppst, weil die aufgenommenen Stückchen nicht zu lang sein dürfen,
denn sonst ergibt das schließlich eine ganz schöne Verzögerung, bis das andere Ende endlich mal was hören kann.

Fazit: Du brauchst auf jeden Fall eine Aufnahmemethode, welche per Streaming aufnimmt und wo man die Daten bereits während der Aufnahme einlesen, umwandlung und versenden kann.

Eventuell ist die bass.dll da schon bissl geeigneter.


PS: Man mag es nicht glauben, aber die Suchfunktion ist nicht ganz umsonst.
http://www.delphipraxis.net/106489-a...-oder-udp.html
http://www.vclcomponents.com/s/0__/a...ponent_delphi/
uvm.




Aber ja, so kann man das natürlich dennoch machen, aber dann mußt du das anders regeln.
z.B.:
- man drückt auf einen Knopf, nimmt auf, bis man loslässt,
- dann wird die Aufnahme umgewandelt, übertragen und danach drüben abgespielt.

Das ist dann so ähnlich, wie mit den Walkie-Talkies früher.




Und ja, man kann natürlich die Zeitkrittischen Teile auf mehrere Threads aufteilen.
z.B.:
- in einem Thread aufnehmen
- im nächsten Thread parallel dazu das bereits aufgenommene Umwandeln
- im dritten Thread das übertragen,
- dann 'nen Thread zum Empfangen des Tons der Gegenseite (den Thread braucht man nicht unbedingt selber machen ... je nach Übertragungskomponenten)
- und dann 'nen Thread zum Abspielen des Tons

Je nach Auslastung kann man auch mehrere Dinge zusammen in einem Thread machen.

[onepiecefreak2]

Deine Idee mit den Threads, wie du sie aufteilst, dachte ich mir auch schon. Das Problem ist nun Folgendes: Ich brauche etwas um das schon vorhandene Tonmaterial umzuwandeln. Wie ich schon in einem früheren Post anmerkte würde ich zum Umwandeln gerne LAME benutzen. Es ist allerdings so, dass ich nicht weiß wie ich das einbinde.

Hast du vllt. eine Idee? Oder gleich einen Code dafür?

Noch interessant wäre: Wenn ich die Datei sofort dann umwandle, wenn sie am Entstehen ist, muss ich da auf mehr Dinge achten, als wenn ich eine schon fertige Datei umwandle?

[Perlsau]

Also ich weiß nicht: Erst willst du einen Voice-Chat basteln, jetzt willst du plötzlich vorhandenes Tonmaterial umwandeln. Das sind zwei völlig unterschiedliche Dinge! Dann schreibst du im Eingangsposting, du möchtest etwas entwickeln, bittest aber ständig um fertigen Code, weil dir die für dein Vorhaben notwendigen Grundlagen fehlen. Daher würde ich dir empfehlen, dich erst einmal mit diesen Grundlagen ausführlich zu befassen, damit du überhaupt verstehst, was die Hinweise, die man dir liefert, bedeuten und wie sie umzusetzen sind.

[onepiecefreak2]

Ich will nichts anderes in jedem Post. Durch die Antworten der anderen ist mir nur klar geworden, dass es nicht einfach nur Sprechen und Übertragen ist, sondern aufnehmen, umwandeln, senden, empfangen, evtl. nochmal umwandeln, abspielen. Seitdem versuche ich Punkt für Punkt das Wissen der anderen zusammenzuttragen.

Jetz sind wir beim ersten Umwandeln, da wir ja schon aufnehmen können.

Zudem habe ich schon Grundlagenwissen im Übertragen von Strings über einen TCP/IP-Server. (Ja, ich weiß Strings sind nicht dasselbe, wie Audio-Dateien)

Und zum Letzten. Ich verlange keinen "fertigen" Code. Ich bitte um Codeausschnitte oder einzelne Befehle mit evtl. Erklärung. Alles damit ich so flexibel wie möglich bei meinem noch beschränkten Wissen sein kann. (Ich hoffe durch diesen Thread mein Wissen zu erweitern)

Und bevor noch weiteres kommt. Wer die Vorposts gelesen hat, bemerkt, dass ich auch sehr wohl in der Lage bin mir eigenes Wissen anzueigenen (Benutzen von Threads) oder durchaus Google oder die Suchfunktion hier zu bemühen.

Also nochmal: Ich will jetzt NICHT nur wissen wie ma umwandelt. Es ist einer der vielen Schritte die getan werden müssen, um voranzukommen.

[Perlsau]

Wie Himitsu dir oben bereits mitgeteilt hat, benötigst du für dein Vorhaben eine Möglichkeit

1. Sound via Streaming von einem Mikrofon aufzunehmen
2. augenommenen Sound sofort zu verarbeiten
3. augenommenen Sound zu versenden.

Das bietet z.B. die Bass.dll, in die du dich aber erst einmal einarbeiten mußt. Diese Library bietet auch Möglichkeiten, Streams zu encodieren. Deine Aufnahmetechnik ist nicht dazu geeignet, dein Vorhaben umzusetzen, wie dir Himitsu oben ebenfalls bereits erläutert hat. Aber du kannst ja jetzt schon aufnehmen, wie du schreibst. Und Strings versenden ... alle Achtung!

Für mein PC-Pulsmess-Programm via Mikrofon habe ich mich etliche Tage eingehend mit den entsprechenden Features der Bass-Library und den verfügbaren Add-Ons befaßt. Daher weiß ich sehr , daß dir für dein Vorhaben noch eine Menge Grundlagen fehlen. Du hast, wie du schreibst, massig Zeit, also ran an den Speck.

Und wenn du jetzt nochmal erwähnst, daß du schon weißt, wie man Strings versendet, dann ruf ich den Bademeister :stupid:
Du solltest auch nicht ständig in der Wir-Form schreiben, denn es ist dein Vorhaben und dein Projekt. Niemand will hier das Projekt mit dir gemeinsam entwickeln, auch wenn du das im Eingangsposting gefordert hattest.

[onepiecefreak2]

Nun, ich danke für deine äußerst hilfreiche Information mit der bass.dll. Ich hatte sowieso schon mal gehört, dass die dafür wohl am geeignetsten wäre.

Ich schreibe nur "wir", weil IHR MIR helft. Das verstehe ich unter dem Personalpronomen "Wir". :-D

Und das mit den Strings soll auch nicht dazu dienen, meine nichtvorhandene Genialität zu unterstreichen. :)

Nun ich finde zumindest toll, dass du deine Kritik an mir in freundlicher Form verpackst und nicht gleich ausfallend oder so wirst.

Ok, bin dann erstmal in bass.dll einlesen. Sollte ich Fragen dazu haben, wende ich mich hier an euch oder an dich Perlsau.

Bis irgendwenn.:thumb:

[Perlsau]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262307)

Nun, ich danke für deine äußerst hilfreiche Information mit der bass.dll. Ich hatte sowieso schon mal gehört, dass die dafür wohl am geeignetsten wäre.

Wenn man das Prinzip dieser Library erst einmal verstanden hat, ist sie ein mächtiges Werkzeug. Ich nehme damit z.B. Töne auf, die in Echtzeit analysiert und in einem Spektrometer angezeigt werden. Und ich analysiere den aufgenommenen Stream nach Beats, wobei zuvor ein Bandfilter zum Einsatz kommt, der nur tiefe Frequenzen durchläßt – alles mit der Bass.dll und ohne den Stream zu speichern. Letzteres würde viel zu lange dauern und damit den kontinuierlichen Fluß der Ton-Information unterbrechen.

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262307)

Ich schreibe nur "wir", weil IHR MIR helft. Das verstehe ich unter dem Personalpronomen "Wir". :-D

Echt? Oben klang das aber irgendwie anders:

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262307)

Ich würde mich sehr darüber freuen, wenn wir in diesem Thread einen funktionstüchtigen Voicechat fertig gebastelt bekommen.

[onepiecefreak2]

Ja, gut ok... was soll ich da noch zu sagen :D

Hab schon viele gute Tutorials zur bass.dll gefunden. Wenn du noch Seiten kennst auf denen man sich gut in die Materie der dll einlesen kann, wäre ich sehr dankbar.

[Perlsau]

MeMP - Mein einfacher Mp3-Player
... oder im Delphi-Treff: Mein einfacher Mp3-Player
... und als PDF-Datei

Soundkarten-Messung I: Steuerung mit der BASS.DLL
Soundkarten-Messung II: Amplitude, Frequenz und Phase

Bass.dll Tutorial im Blitzforum

... und viele weitere via Google

... und nicht zu vergessen: die jeweiligen Help-Dateien der diversen Bass-Libraries. Die sind äußerst hilfreich, wenn man die genau Syntax einer DLL-Funktion nicht kennt.

[Namenloser]

Ich würd auch erst mal so vorgehen, nur Aufnahme und Ausgabe von Audiodaten hinzubekommen. Das alleine wird schon einige Tage Zeit beanspruchen.

Wenn du das hast, kannst du mal versuchen, die Daten über das lokale Netzwerk zu verschicken, erst mal ganz naiv per TCP. Ich würd das auch erst mal unkomprimiert machen, bzw. mit einer sehr einfachen, selbstgestrickten Echtzeit-Kompression: Einfach auf 10250 Samples/Sekunde downsamplen mit 8 Bit pro Sample. Das wären 82 kbit/s, sollte sich also bequem übers Netzwerk übertragen lassen. Die Qualität wird sehr schlecht sein, aber man sollte zumindest irgendwas hören.

Danach kannst du gucken, ob du es schaffst, einen vernünftigen Audiocodec einzubinden, oder dir UDP mal anschauen.

[onepiecefreak2]

Erstmal danke für die ganzen Links, mein Bester. ;)

Nun zum Namenlosen:

@Namenloser
Schau mal in den Post von mir, wo ich Code eingefügt habe. Dieser Code ist zur Aufnahme und Speicherung einer Audio-Datei. Dieser Punkt ist also schon fertig. ;)

Vllt. kommt das an dieser Stelle schon zu spät, aber ein Videochat über ein lokales Netzwerk war mein Ziel. Also im Grunde genommen würde mir so einer schon reichen. :-D

Aber deine Idee mit dem TCP-Server hatte ich auch schon. Ich muss halt nur schaffen den Audio-Stream von der bass.dll auch in Echtzeit übertragen zu können. Das ist das Problem nach der bass.dll.
Oder ich bin noch nicht an der Stelle angekommen wo erklärt wird, wie ich eine solche Netzwerkübertragung mit der bass.dll bewerkstellige. :)

Naja, bis bälde.

[nuclearping]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262317)

Erstmal danke für die ganzen Links, mein Bester. ;)
Schau mal in den Post von mir, wo ich Code eingefügt habe. Dieser Code ist zur Aufnahme und Speicherung einer Audio-Datei. Dieser Punkt ist also schon fertig. ;)

Nein, der Punkt zeigt dir lediglich, wie du auf rudimentärste Art Daten über ein Mikrofon mit Hilfe der Windows Media Player API in eine WAV-Datei speichern kannst.

Wie die anderen schon geschrieben haben, hat das nichts mit dem zu tun, was du vorhast. Wenn du aber hier einen Voice-Chat (oder gar einen Video-Chat, wird ja immer besser :mrgreen:) hinbekommen willst, wirst du diesen Codeschnippsel nicht weiterverarbeiten können, weil du Daten in einem kontinuierlichen Stream aufnehmen und gleichzeitig verarbeiten musst, dh. komprimieren (oder wie hier vorgeschlagen runtersamplen), versenden und nebenbei das was du (vom Server / Gegenstelle) empfängst ebenfalls verarbeiten.

[Namenloser]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262317)

@Namenloser
Schau mal in den Post von mir, wo ich Code eingefügt habe. Dieser Code ist zur Aufnahme und Speicherung einer Audio-Datei. Dieser Punkt ist also schon fertig. ;)

Das Problem ist, dass dir die Datei nichts bringt. So kannst du höchstens einen Anrufbeantworter programmieren, aber du willst doch wohl live mit deinem Gegenüber reden.

Das heißt du brauchst auch Live-Zugriff auf die Audiodaten, ohne den Umweg über eine Datei. Das geht zum Beispiel mit der bass.dll.

[Perlsau]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262317)

Erstmal danke für die ganzen Links, mein Bester. ;)

Wenn du die hinter den Links verborgenen Informationen nicht studierst, waren sie zwecklos und ich habe mir die Mühe umsonst gemacht.:cry:

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262317)

Schau mal in den Post von mir, wo ich Code eingefügt habe. Dieser Code ist zur Aufnahme und Speicherung einer Audio-Datei. Dieser Punkt ist also schon fertig. ;)

Ich kann mich hier Namenloser und nuclearping nur anschließen: Auf dem Weg über die Datei kommst du nicht weiter. Offenbar hast du die entsprechenden Hinweise, die dir bereits mehrfach geliefert wurden, erfolgreich ignoriert. Dann ist dir nicht wirklich zu helfen.

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262317)

Vllt. kommt das an dieser Stelle schon zu spät, aber ein Videochat über ein lokales Netzwerk war mein Ziel. Also im Grunde genommen würde mir so einer schon reichen. :-D

Jetzt soll's plötzlich ein Video-Chat sein? Junge Junge ... Jetzt mach doch mal langsam und gehe einen Schritt nach dem anderen :gruebel:

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262317)

Aber deine Idee mit dem TCP-Server hatte ich auch schon. Ich muss halt nur schaffen den Audio-Stream von der bass.dll auch in Echtzeit übertragen zu können. Das ist das Problem nach der bass.dll. Oder ich bin noch nicht an der Stelle angekommen wo erklärt wird, wie ich eine solche Netzwerkübertragung mit der bass.dll bewerkstellige. :)

Versuch doch einmal, produktiv zu lernen: Du nimmst dir ein Tutorial und programmierst das durch. Einfach nur drüberfliegen und querlesen, bis man ein Stichwort findet, das die gesuchten Informationen einleitet, führt nur äußerst selten zum Ziel. Lerne doch erst einmal, wie man mit der Bass.dll eine Sound-Datei aufnimmt. Dabei werden die vom Mikrofon erzeugten Signale in einen Stream gespeichert. Du mußt dich mit der Callback-Funktion (im Tutorial ausführlich beschrieben) auseinandersetzen und dort die hereinkommenden Signale zeitnah verarbeiten. Ein geübter Programmierer, der wie ich seit Jahren jeden Tag 8 bis 10 Stunden mit Delphi arbeitet, benötigt dafür sicher einen Tag, eher mehr, wenn er die Bass.dll noch nicht kennt. Bei einem ungeübten Programmierer mit lediglich rudimentären Kenntissen würde ich erfahrungsgemäß eine Woche einplanen – ich war schließlich auch mal Anfänger und habe nicht vergessen, wie das war.

Wenn du dann begriffen und erfolgreich umgesetzt hast, wie man einen Audiostream erzeugt und verarbeitet, kommt der nächste Schritt: das Codieren des Streams. Aber so weit bist du jetzt noch nicht.

[Aphton]

Ich versteh nicht, warum das jeder so verkompliziert.
Ist im Grunde doch ganz einfach - Windows bietet einem bereits alles an, was man braucht: Sockets + WaveIn/WaveOut Funktionen
Im Anhang befindet sich ne kleine Demo; die habe ich in ca. 2h programmiert und auf Windows 7 getestet.

Das sind 300 Zeilen Code, mehr nicht!

Edit: Hab die DPR Datei auch noch hochgeladen..
Die Tonquali habe ich runtergedreht (1 Channel mit 11025 Samples / Sek, wobei 1 Sample = 1 Byte..) und einfachheitshalber nur TCP verwendet (mit internen Stream Klassen.. zum Streamen halt). Darauf kannst du ja nun aufbauen.

[onepiecefreak2]

Ok, ich muss hier etwas klarstellen... das ich Videochat geschrieben habe, ist mir gar nicht aufgefallen. :lol:

Ic wollte Voicechat schreiben... SRY an der Stelle. Mein Problem aber, dürfte sein, dass ich versuche alles auf einmal lernen und einbringen zu wollen. Deswegen klingt das alles auch so wirsch was ich vorhab :oops:.

@Perlsau
Die Links habe ich bereits alle durchgelesen. Manche davon kannte ich schon. Das Aufnehmen einer Sounddatei ist mir, wie du mir als Ziel gesetzt hast, schon möglich. Natürlich muss ich aber Streamen und nicht aufnehmen und Datei speichern.

Was ich aber am geilsten finde an diesem Thread, dass hier so viele "bekannte" Gesichter reinschreiben. Mavarek oder Aphton habe ich im Zusammenhang mit solchen Audio-Themen hier im Forum immer wieder rumgeistern sehen. :o

Ich werde mir mal den Code von Aphton ansehen.

Bis zum nächsten Kommentar.

[nuclearping]

Zitat:

Zitat von Aphton (Beitrag 1262323)

Ich versteh nicht, warum das jeder so verkompliziert.

Wir verkomplizieren es nicht. Wir versuchen lediglich, ihn auf dem Boden zu halten, damit aus dem Vorhaben keine "Eintagsfliege" wird, da offensichtlich viel Grundlagenwissen fehlt und er damit zu naiv rangeht. Ist ja nicht bös' gemeint, auch wenn's vielleicht ein wenig harsch klingt. :mrgreen:

[onepiecefreak2]

Seid so kritikfreudig, wie auch sonst. Ich habe ein Vorhaben. Das will ich verwirklichen und wenn ich meine Ausbildung anfange, kann ich auch nicht einfach sagen, dass ich keine Lust mehr habe. Demnach nutze ich meine Zeit, um zu lernen, euren Räten zu folgen und das Ding zuende zu stellen.

@Aphton
Dein Programm ist beeindruckend klein. Ich teste es auch noch mit einem Freund. Sollte es funktionieren und unseren Ansprüchen genügen, werde ich es, wenn du erlaubst als Vorlage zum Lernen nutzen und für unsere Zwecke noch auf eine schöne Form bringen.

Heißt natürlich nicht, dass ich aufhöre z.B. mit der bass.dll zu lernen oder auch noch meinen eigenen VoiceChat schreibe. Also der Thread ist wegen Aphton's VoiceChat nicht schon zuende.

Danke schön.

[Mavarik]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262354)

Was ich aber am geilsten finde an diesem Thread, dass hier so viele "bekannte" Gesichter reinschreiben.

Ups... Sieh mal einer an zu welchem Club ich hier gehöre...

Zitat:

Zitat von Groucho-Marx

"Ich mag keinem Club angehören, der mich als Mitglied aufnimmt."

Na egal...

BTB:

Thema 1 Audioaufnahme:
Die "Komponente" muss einen möglichst kleinen zum UDP Package großen Audiostream aufnehmen (Größe nach dem Codec). Bedeutet
Die nativen Audiodaten in Puffer 1 schreiben. Wenn der Puffer voll ist diesen durch einen Codec jagen und zwar einen der
KEINE Datei braucht. Hierfür sind VOIP/Telefon Codecs besser geeignet.
Die Routinen muss also einen Backcall/Interrupt auslösen, um das Samplen auf Puffer 2 um zu stellen und den Codec starten.

Thema 2 Übertragung:
Wenn der Codec fertig ist, müssen die Daten per TCP/IP oder UDP übertragen werden. Also müssen die Daten so klein sein, dass diese
genau so schnell oder schneller übertragen werden können, als dass aufnehmen des Puffers dauert. (inkl.Codec)
Also brauchst Du eine adaptive Qualitätseinstellung um die Größe an zu passen.

Weil? Was tun, wenn der Puffer2 schon voll ist, aber der Puffer 1 noch nicht codiert ist?
- Codec zu langsam

Was ist wenn der Codec schon wieder gestartet wird, obwohl der Übertragungspuffen noch nicht leer ist?
- 2. Puffer anlegen... 3. Puffer anlegen 4. usw. und hoffen, das der Sprechende mal ne pause macht. bzw.
Ab dem 3. Puffer die Aufnahme Qualität runter bzw. die Codec Kompression hoch setzen.

Ach ja unnötig zu erwähnen, dass Du natürlich parallel dazu die ganze Zeit auch noch Audio Streams empfangen musst und diese an die Soundkarte ausgeben musst.

Optimierung:
Sprachpausen, Hintergrund Geräusche und Echos erkennen und eliminieren.

Sprachpausen als Token (Warte n Millisekunden) (5 Byte) übertragen und nicht das dem Codec überlassen.

So kann es etwas werden...

Mavarik

[onepiecefreak2]

So,

ich habe mich mal durch Aphtons Programmcode gefressen. Nun ich bin weit gekommen, kann allerdings das Programm nicht neu compilieren, weil ich zB mal die Samplerate erhöht habe. Er fordert eine aphtonSocket.dcu. Da ich die nicht habe, habe ich den Verweis aus dem uses-Bereich gelöscht und kennt danach die REGION-Einklammerungen nicht mehr.

Also wenn Aphton mir die dcu-Datei gibt oder mir sagt, wie ich es auch ohne diese neu compilieren kann, wäre ich sehr dankbar.

Und nochmal, nicht dass es falsch rüberkommt, ich wollte nur die Samplerate mal höher stellen. Nichts anderes.
Danke!

[Aphton]

Joa, hab ich vergessen.. Ist nur ein kleiner WinSock Wrapper..

[onepiecefreak2]

Danke erstmal dafür Aphton.

Nun mein 2. Problem mit deiner Annwendung. Ich versuche im Moment alles aufzuspalten, um deinen Code über 2 separate Formen, eine für den Server und eine für den Client, zu packen. Bis auf das Hauptprogramm, an dem ich gerade sitze. In diesem befindet sich diese Zeile:

Delphi-Quellcode:

if Client.ReceiveLength > 0 then

und diese:

Delphi-Quellcode:

if Accept.ReceiveLength > 0 then

Deren Bedeutung ist mir durchaus bewusst, aber das Programm meint zu diesen Zeilen folgendes:
[Fehler] Unit1.pas(242): Undefinierter Bezeichner: 'ReceiveLength'

Ich habe deinen Code bis jetzt 1:1 übernommen und ihn auch schon mehrmals durchgeschaut. Es gibt keine Deklaration für ReceiveLength. Zumal ja nichts ungewöhnliches, da ReceiveLength zu einem Befehlaufruf gehört. Aber warum kennt Delphi diesen Befehl nicht? Oder funktioniert ReceiveLength nur in einer Konsolenanwendung?

Danke im Vorraus.

P.S: Liegt es an der Samplerate von 'nur' 11025, dass der Ton ruckelt? Ich habe es mal mit mir selbst getestet (da ich mich nämlich auch selbst hören kann ^^) und habe festgestellt, dass es hier und da einfach mal zu Aussetzern kommt. Das sind sicher diese verlorenen Daten, die ja vermieden werden sollen.

[Sir Rufo]

Wirf einen Blick in die aphtonSocket.pas, dann springt es dich an ...

[onepiecefreak2]

Also ist der Fehler auch auf die .pas zurückzuführen? Naja, konnt' ich mir ja gleich denken. :stupid:

[onepiecefreak2]

So ein paar neue Fehler:

Delphi-Quellcode:

IF ReceiveBuffer.Size >= WaveHdr.dwBufferLength THEN BEGIN

Delphi-Quellcode:

Move(Pointer(Integer(ReceiveBuffer.Memory) + WaveHdr.dwBufferLength)^,ReceiveBuffer.Memory^, ReceiveBuffer.Size - WaveHdr.dwBufferLength);

Delphi-Quellcode:

ReceiveBuffer.Size := ReceiveBuffer.Size - WaveHdr.dwBufferLength;

Fehler: "Vorzeichenbehaftete und -lose Typen werden kombiniert - beide Operanden werden erweitert"

Delphi-Quellcode:

BytesSent := Client.SendBuffer(SendBuffer.Memory^, Min(SND_RCV_SIZE, SendBuffer.Size))

Fehler: "Undefinierter Bezeichner: 'SendBuffer'"
Fehler: "Nicht genügend wirkliche Parameter" (Nach 'SendBuffer.Memory^')

Delphi-Quellcode:

IF Assigned(Client) THEN
   BytesSent := Client.SendBuffer(SendBuffer.Memory^, Min(SND_RCV_SIZE, SendBuffer.Size))
   ELSE BytesSent := Accept.SendBuffer(SendBuffer.Memory^, Min(SND_RCV_SIZE, SendBuffer.Size));
IF BytesSent > 0 THEN BEGIN

Fehler: ';' erwartet, aber 'IF' gefunden (Dabei waren die letzte und vorletzte Zeile markiert)

Hier nochmal der komplette Code zu den ganzen Fehlermeldungen:

Delphi-Quellcode:

// Extraction of wavehdrs
IF ReceiveBuffer.Size >= WaveHdr.dwBufferLength THEN BEGIN
   Move(ReceiveBuffer.Memory^, WaveHdr.lpData^, WaveHdr.dwBufferLength);
   Move(Pointer(Integer(ReceiveBuffer.Memory) + WaveHdr.dwBufferLength)^,ReceiveBuffer.Memory^, ReceiveBuffer.Size - WaveHdr.dwBufferLength);
   ReceiveBuffer.Size := ReceiveBuffer.Size - WaveHdr.dwBufferLength;
   ReceiveBuffer.Seek(0, soFromEnd);
   SendToPlayerThread();
   END;
end;

procedure processSendBuffer();
VAR BytesSent: Integer;
begin
IF Assigned(Client) THEN
   BytesSent := Client.SendBuffer(SendBuffer.Memory^, Min(SND_RCV_SIZE, SendBuffer.Size))
   ELSE BytesSent := Accept.SendBuffer(SendBuffer.Memory^, Min(SND_RCV_SIZE, SendBuffer.Size));
IF BytesSent > 0 THEN BEGIN
   Move(Pointer(Integer(SendBuffer.Memory) + BytesSent)^,SendBuffer.Memory^, SendBuffer.Size - BytesSent);
   SendBuffer.Size := SendBuffer.Size - BytesSent;
   SendBuffer.Seek(0, soFromEnd);
   END;
end;

Also ich komm mir immer dümmer vor. Ich habe nun aber auch keine Möglichkeit mehr etwas hinzuzufügen, außer Aphton hat noch eine .pas oder so vergessen. Wäre toll, wenn ihr mir bei der Fehlersuche helfen würdet... vorallem Aphton ^^

[Aphton]

Der erste Fehler mit dem Vorzeichen kannste ignorieren, da der Compiler die Datentypen sowieso selber anpasst. Das sollte kein Fehler sondern eine Warnung sein.


Alle folgenden Fehler basieren darauf, dass du die aphtonSocket Pascal-Datei nicht in der Uses hast bzw. auch nicht im selben Ordner.

[Aphton]

Zitat:

Zitat von onepiecefreak2 (Beitrag 1262653)

P.S: Liegt es an der Samplerate von 'nur' 11025, dass der Ton ruckelt? Ich habe es mal mit mir selbst getestet (da ich mich nämlich auch selbst hören kann ^^) und habe festgestellt, dass es hier und da einfach mal zu Aussetzern kommt. Das sind sicher diese verlorenen Daten, die ja vermieden werden sollen.

Der Ton sollte nicht ruckeln, vorallem deswegen, weil zwei Puffer per WaveIn abwechselnd an das System zur Aufnahme überreicht werden - das ganze in nem Thread völlig ungestört.
Vlt hast du da ja etwas geändert, könnte daran liegen.

[Perlsau]

[off topic]

Wie war da jetzt nochmal?

Zitat:

Zitat von Aphton

Ich versteh nicht, warum das jeder so verkompliziert. Ist im Grunde doch ganz einfach - Windows bietet einem bereits alles an, was man braucht: Sockets + WaveIn/WaveOut Funktionen

Ich meine, schön und gut, du lieferst ihm eine fertige Lösung, für deren Verwendung und Einsatz der TE nix weiter dazulernen und die er auch nicht verstehen muß – wenn sie denn funktionieren würde. Ob das nachhaltig ist, darf bezweifelt werden ... :stupid:

Da fragt man sich doch öfter mal, worum's eigentlich geht: Daß der Fragesteller eine Lösung erarbeiten kann oder daß sich Hilfsbereite gegenseitig im Anbieten der besseren Lösung ausstechen. Was glaubst du wohl, weshalb der TE nun auf deine Lösung eingeht? Ganz einfach: Weil der glaubt, das ohne weiteren Hirnschmalz einsetzen und als eigene Lösung ausgeben zu können – er nimmt einfach den Weg des scheinbar geringsten Widerstandes. Also ich bin da jetzt endgültig raus ...

[/off topic]

[Aphton]

Zitat:

Zitat von Perlsau (Beitrag 1262668)

[off topic]

Wie war da jetzt nochmal?

Zitat:

Zitat von Aphton

Ich versteh nicht, warum das jeder so verkompliziert. Ist im Grunde doch ganz einfach - Windows bietet einem bereits alles an, was man braucht: Sockets + WaveIn/WaveOut Funktionen

Ich meine, schön und gut, du lieferst ihm eine fertige Lösung, für deren Verwendung und Einsatz der TE nix weiter dazulernen und die er auch nicht verstehen muß – wenn sie denn funktionieren würde. Ob das nachhaltig ist, darf bezweifelt werden ... :stupid:

Da fragt man sich doch öfter mal, worum's eigentlich geht: Daß der Fragesteller eine Lösung erarbeiten kann oder daß sich Hilfsbereite gegenseitig im Anbieten der besseren Lösung ausstechen. Was glaubst du wohl, weshalb der TE nun auf deine Lösung eingeht? Ganz einfach: Weil der glaubt, das ohne weiteren Hirnschmalz einsetzen und als eigene Lösung ausgeben zu können – er nimmt einfach den Weg des scheinbar geringsten Widerstandes. Also ich bin da jetzt endgültig raus ...

[/off topic]

Wo bleibt hier die ~"Unschuldsvermutung"?
Wer sagt außerdem, dass man nur durch Erarbeiten einer Lösung etwas lernen kann? Man kann genauso gut auch durch das analysieren einer Lösung etwas - oder, wenn man Neuling ist, viel mehr lernen. Das kann ich zumindest von mir behaupten!
Ob man es tut oder nicht, ist einem selbst überlassen - nicht dir. Ob der TE was lernt oder nicht, wird auf langer Sicht ihn positiv/negativ beeinflussen.

Ich war übrigens lange Zeit deiner Ansicht, dass hat sich aber geändert - ich weiß vorallem wegen meiner Uni, dass man von Lösungen auch etwas lernen kann. Viele Sachen sind vlt. zu trocken und man kann sich praktisch nichts drunter vorstellen, bis einem gezeigt wird, dass man z.B. damit alles so anstellen kann. Dann machts klick. Danach kann man nochmal zurück zur Theorie und versteht dann einige Definitionen usw. viel besser.
Man darf das ganze nicht als eine Einbahnstraße sehen..

Achja, noch etwas war mir hier auf der DP aufgefallen ist - ist also nicht an dich speziell gerichtet, aber als Beispiel nehm ich da mal etwas von dir:

Zitat:

Zitat von Perlsau

Jetzt soll's plötzlich ein Video-Chat sein? Junge Junge ... Jetzt mach doch mal langsam und gehe einen Schritt nach dem anderen

Zunächst einmal, es ist mir bewusst, dass du davon ausgehst, dass der TE einfach ein "Neuling" ist. Der Rat ist auf erstem Blick vlt. gut gemeint - es hilft den meisten Neulingen auf dem Boden zu bleiben usw.
Das ganze ist trotzdem richtig demotivierend und herablassend. Du kannst nie genau wissne, wozu jemand in der Lage ist.
Ich bin in letzter Zeit öfters auf gamedev unterwegs und da tauchen auch immer Threads auf wo dann gefragt wird, wie bestimmte eig. rel. komplexe Rendertechniken implementiert werden können. Da sind die ersten Meldungen nicht "Junge Junge".. Die gehen da direkt auf die Theorie ein und erklären grob alle Schritte, die gemacht werden müssen, um das Ziel zu erreichen. Ganz egal, wie komplex das Thema ist und wie "grün" der TE klingt.
Verlinkt wird auch, ohne vorher die Person zu beschimpfen, dass nicht ordentlich gesucht wurde. Und siehe da, nach einigen Tagen sieht man dann im selben Thread schöne Resultate und jeder ist zufrieden! Ich finde das viel professioneller!
(Ok, komplette Lösungen wie von mir, werden vlt nicht oft gepostet :-D Das tue ich aber, weil mir langweilig ist, ich Zeit habe und am Thema interessiert bin..)

Ich kann mich noch genau erinnern, wie einer meinte, ich sollte es mit dem Programmieren sein lassen, als ich hier eine meiner ersten Projekte veröffentlichte. Das habe ich bis dato nicht vergessen! Ich finde solches Verhalten unakzeptabel.
Mich kotzts fast schon an >.> Wollt ich mal kurz loswerden :P Daher meine Bitte - seid nicht so.
(Hiermit will ich übrigens nicht sagen, dass ich HÜs für andere machen OK finde. Da sollte ein feiner Unterschied erkennbar sein.)

/Offtopic

[jobo]

Zitat:

Zitat von Aphton (Beitrag 1262678)

Ich finde solches Verhalten unakzeptabel.
Mich kotzts fast schon an >.> Wollt ich mal kurz loswerden :P Daher meine Bitte - seid nicht so.
/Offtopic

:thumb:

[Perlsau]

Mein lieber Aphton,

deine Einwände sind akzeptabel und verständlich, wenngleich ich vieles wohl doch anders sehe als du. Für mich heißt entwickeln eben nicht kopieren, sondern – um es mal bildlich auszurücken – das Knäuel an Informationen und irreführenden Vorstellungen in meinem Hirn ent-wickeln, auf daß die Informationsmenge übersichtlich und anwendbar wird.

Auch ich habe nicht vergessen, wie das als Anfänger war, und auch ich hatte wie wohl die meisten Programmierer hochtrabende Vorstellungen und Ziele, die ich aufgrund mangelnder Erfahrung nicht umsetzen konnte. Nachdem ich das erkannt hatte – denn dieser Weg führte in eine Sackgasse –, schraubte ich meine Ziele drastisch herunter und begann quasi noch einmal von vorne, auch weil ich zuvor mit Turbo Pascal gearbeitet hatte und vieles davon in Windows nicht mehr zu gebrauchen war. Ich arbeitete mich durch etliche Einsteiger-Bücher und -Tutorials, begann mit einfachsten Anwendungen wie Adressverwaltung mit typisierten Dateien usw. Erst ein paar Jahre nachdem ich mit Delphi 3 regelmäßig geübt hatte, war ich in der Lage, meine erste semi-professionelle Anwendung zu entwickeln (Veranstaltungs- und Mitgliederverwaltung für einen überregional organisierten Künstlerinnen-Verein mit Delphi 7 personal). Ich benötigte für die beiden Programme fast ein Jahr, was ich heute in ein paar Wochen erledigen könnte (Datenbank, Chart-Komponente, mehr Übung).

Allzu oft erlebe ich hier und in anderen Delphi-Foren jedoch, daß es den Fragestellern einzig darum geht, irgend einen zu finden, der ihnen den Code schreibt. Sicher, man kann diese Einschätzung als überheblich und arrogant etikettieren, was auch häufig geschieht, weil jeder dieser Kandidaten verständlicherweise versucht, den Eindruck zu verwischen, er habe eigentlich kein echtes Interesse am Programmieren, sondern möchte nur eine Copy'n'Paste-Lösung, egal wie. Oft sind diese Leute dann nicht mal in der Lage, die angebotenen Lösungen auch umzusetzen, eben genau so, wie es unser TE hier vorführt. Ich wäre damals als Anfänger auch nicht unbedingt in der Lage gewesen, komplexen Code für so umzubauen, daß er meinen eigenen Anforderungen genügt oder gar selbst Code für komlexere Anwendungen zu entwickeln. Dafür mußte ich mich erst mühevoll einarbeiten, das hat viel Zeit und Ausdauer erfordert, zumal ich mit meinen 53 Jahren auch nicht mehr der Jüngste bin. Mir wäre, nachdem mir damals mein Anfängerstatus richtig bewußt geworden war, nicht im Traum eingefallen, z.B. einen Chat schreiben zu wollen oder eine komplexe Datenbank-Anwendung oder eine Sound- und Video-Bearbeitung.

Aus den genannten und einigen weiteren ungenannten Gründen (z.B. wenn ich sehe, daß ein User nicht mal weiß, daß man Klassen, die man verwenden will und die sich in eigenen Units befinden, in die Uses einbinden muß: das ist Basiswissen!) finde ich mein Vorgehen bzw. meine Reaktion auf bestimmte Usertypen nicht wirklich ungerechtfertigt oder inakzeptabel. Auch scheine ich nicht der einzige zu sein, dem es so ergeht bzw. der so empfindet, nur traut sich das offenbar kaum noch einer zu sagen, weil hier schon derart heftige Angriffe, die bis zur weinerlichen Anklage gingen, gefahren wurden. Das schreckt natürlich ab, und genau das war und ist auch der Zweck solcher Angriffe. Und nein, ich fühle mich nicht von dir angegriffen, du bleibst in deiner Argumentation sachlich und freundlich, auch wenn du Kritik äußerst. Das ist für mich akzeptabel und durchaus erwünscht. Doch letztendlich plädierst du dafür, daß man sich immer die Zeit nehmen soll, ausnahmslos jedem immer alles haarklein zu erklären, auch wenn man den Eindruck hat, daß die Erläuterungen nicht mal im Ansatz verstanden werden oder daß erst gar kein echtes Interesse besteht. Das kannst du ja machen, davon hält dich keiner ab, aber solltest du dann nicht auch akzeptieren, daß andere die Sache vielleicht anders sehen?